Bugzilla – Bug 6442
Firmware should decode to PCM even when paused
Last modified: 2010-05-14 14:07:52 UTC
The firmware should always try to fill the output buffer even when paused. The current implementation causes some issues when you have a codec with an output threshold (ogg, wma, and high-rate flac) playing on an SB and a Transporter synced, because they decode at different rates due to the CPU speed difference. I have not tested if Alan's sync fixes handle this case or not, so it may not be as big of a problem anymore.
Sean: did your recent transporter changes address this? Should we be fixing this for 7.0?
No but it's something we should look at in the future to improve syncing, as this would make the startup more deterministic. It would ensure that Transporter and Squeezebox have the same startup latency, even if they are decoding different formats. It also would reduce the chance of under-running the decode buffer if the codec is lagging. If this were addressed then we should not need the kludgy "threshold" setting. It would also reduce track startup time by perhaps 50-100ms, because the decoder would be getting a head start while the streambuf is being filled. Architecturally it is the Right Thing to do, although there may have been some implementation challenge I'm not aware of.
This would certainly be a help but there are some implications for the sync code. Squeezeslave already does this and one has to wait quite a while for the track to start, because the decode buffer does not reach the required fullness to trigger track-start until the output buffer has been filled. This is especially a problem for radio stations because of the real-time nature of the feed. Fixing this is not a big deal - it just needs to be considered as part of the work.
Too risky to fix, and any problems will be taken care of by Alan Young's 'new streaming' feature in 7.2
Sean notes that this will improve new-track startup time for the first track or when skipping to a new track, so it is worthwhile. This has to include a change to the behavior of the STMl packet to be sent after a certain number of bytes received instead of based on buffer fullness status.
The is fixed for squeezeplay in jive r3307, for 7.3. We should evaluate how well this fix works, and port it to ip3k in a later release: > Decode to PCM even when paused. This fixes a couple of bugs, an audio glitch > when playback starts and avoiding an auto-pause (that never resumed) on an > audio underrun. > > A delay is still needed before the decoder starts, to prevent immediate > decoder underruns at the start of a track. Also (at least on ip3k) some > decoders assume sufficient data to parse the headers at the start of a track. > > The auto start threshold/STMl has been changed to trigger on the bytes > received, not the fullness of the decode buffer. A future improvement > maybe to trigger on the fullness of the output buffer, but Alan > says that this will require a SC change and should be done in all the > supported player software (squeezeplay, ip3k, etc) at the same time.
Richard has implemented this for SqueezePlay. once it is verified this should be back ported for Transporter
Shouldn't this also be backported for other players? Although the original case notes specifiy the Transporter, as I understand it, this could impact any two players with underlying hardware differences: e.g. SB3 and Controller, etc.
(In reply to comment #8) > Shouldn't this also be backported for other players? Although the original > case notes specifiy the Transporter, as I understand it, this could impact any > two players with underlying hardware differences: e.g. SB3 and Controller, etc. > yes, this would apply to all products.
Changing target to next release
Felix, we should consider this for 8.0 firmware in ip3k.
Targeting based on engineering discussion
I posted this to bug#897 and it applies here as well. I'm going through the bugs that involve all of the problems in my system and responding. So far I'm up to Bug#10682, #19680,#983,#9807,and now#6442. There are different responses in these various bugs. This is not and has never been fixed in my system. I have called, writtten and so many bugs have been opened, closed that I can't track them any more. This has been going on since 7.1!!!! I have a controller that is a useless paperweight. I have thousands of dollars in boxes that give me constant aggravation. At it's best I can sync two or maybe three players. At it's worst, like now, the system has been shut down for the weekend. I bought a new IMAC and configured it with customer service on friday 6/12 with the latest 7.3.3 nightly.
All new Squeezebox products are likely to be based on the SqueezePlay platform. We do not plan to implement any further enhancements to the ip3k firmware or which are targeted specifically at ip3k-based products.
I request that this be reclassified as a bug (and reopened), because the current firmware can have audible sync problems until this is fixed. Admittedly this is very codec-dependent and can often be worked around with server-side transcoding, but I still think fixing it is "The Right Think to Do" (also sprach Sean).