home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Development
General Development (no feature request here!)
Experimental TsReader development
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Owlsroost" data-source="post: 823743" data-attributes="member: 83973"><p>TsReader has never flushed downstream on discontinuities - it risks turning a minor glitch into a much bigger upset (and I've never managed to get it to work without running into lockup problems, even from a separate thread in TsReader - I tried it a while ago for another reason). Also default direct sound renderer doesn't need it.</p><p></p><p>The scheduling code looks OK to me, but a thought occurs - is this is scheduling samples to be put into a downstream render queue ? If so, how long (in time) is the queue ?</p><p></p><p>If the timestamp jump/gap is smaller than the queue length, then waiting for a future render time will just empty the queue a little, without delaying the time when the audio sample is actually presented to the outside world ?</p><p></p><p>Tony</p></blockquote><p></p>
[QUOTE="Owlsroost, post: 823743, member: 83973"] TsReader has never flushed downstream on discontinuities - it risks turning a minor glitch into a much bigger upset (and I've never managed to get it to work without running into lockup problems, even from a separate thread in TsReader - I tried it a while ago for another reason). Also default direct sound renderer doesn't need it. The scheduling code looks OK to me, but a thought occurs - is this is scheduling samples to be put into a downstream render queue ? If so, how long (in time) is the queue ? If the timestamp jump/gap is smaller than the queue length, then waiting for a future render time will just empty the queue a little, without delaying the time when the audio sample is actually presented to the outside world ? Tony [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
General Development (no feature request here!)
Experimental TsReader development
Contact us
RSS
Top
Bottom
