Bugzilla – Bug 3047
Disabling analogue outputs (and other effects) for files requiring digital passthrough
Last modified: 2010-05-07 13:39:22 UTC
I'm interested in the passthrough of digital sound on the SB2/3 (we have [url=http://forums.slimdevices.com/showthread.php?t=19260]AC3 and DTS[/url] working) and wanted to look into the possibility of a certain degree of automation. Specifically: currently to pass digital data through to his amp, the user must set the digital volume to maximum, forbid transcoding (to a lossy format for network bandwidth savings), and of course use only a digital connection from the SB2. I'd like to be able to make those settings automatic when certain songs are played (allowing users to not worry about those settings), and to ensure the analogue outputs are disabled for those songs (silence being better than loud white noise!). Setting aside the detection of whether a song requires this, I know that this change will require a firmware update, and I wanted to request such a change. From looking at the client-server protocol, I see that the 'spdif_enable' byte currently has only three states (on, off, auto). I'm thinking that one possibility would be to grab a bit from that byte which would disable the analogue outputs etc when set to 1. Is this possible? Are there other effects which would be desirable?
(In reply to comment #0) > I'm interested in the passthrough of digital sound on the SB2/3 (we have > [url=http://forums.slimdevices.com/showthread.php?t=19260]AC3 and DTS[/url] > working) and wanted to look into the possibility of a certain degree of > automation. That link should be: http://forums.slimdevices.com/showthread.php?t=19260 (I forgot this wasn't the forum, and that such formatting was unnecessary.)
This thread describes a problem with a receiver re-syncing to a stereo PCM stream after playing a DTS stream: http://forums.slimdevices.com/showthread.php?p=107081#post107081 Another potentially useful effect, therefore, might be to provide hints to receivers in such situations -- perhaps with a brief interruption to the digital output stream (avoiding doing so between pairs of PCM or DTS tracks as it could lead to gaps).
Reassigning Squeezebox firmware bugs to Felix.
Any update on this enhancement request. Can I suggest a bit field be added to the database table holding a record for each track to enable "Digital Direct" for that track much like amps have an "Analog Direct" button. In preferences, users could supply a list of file types to be marked for playback set to Digital Direct. e.g. *.DTS.flac, *.AC3.flac Wen the scanner come across files of these type, the tracks would have the bit field set to 1, otherwise the default would be 0. Then in the server code, any tracks in the database with bDDirect=1, the current settings for the client would be saved and playback settings would be changed as follows ReplayGain = disabled Crossfade = disabled Digital volume control = disabled Playback volume = max The previous settings for the client would be restored when the playlist next come across a track with the bDDirect field set to 0.
Dean, this is the enhancement request we were talking about earlier. Those users that take advantage of the digital pass through functionality add a Squeezebox Boom to their collection would be in for quite a surprise if one was to mistakenly play a DTS or AC3 encoded file since it would result in the raw stream playing through the Boom speakers at high volume. Of course this scenario was possible with our products before it just seems more likely to happen with Boom.
An alternate, weaker, possibility to what Mick mentioned would be (as Steven suggested earlier in my office) to use a separate file type for digital-only files, like .dig.wav or .dig.flac or something.
BTW Since I logged this request, I've tagged all my DTS Flacs with a Genre of DTS and excluded this genre from Random mix. This was to avoid the situation where I was getting white noise from the player in the kitchen which is using analogue outs. The album names also have DTS in the title so I can identify them, to avoid playing them by mistakes.
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.
(In reply to comment #8) > 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. Although this was marked as for SB2/3 when I requested it in 2006, it applies to later products too. We don't want raw DTS/AC3 data being played through the speaker of a Squeezebox Radio, say, just as we wouldn't want it on the analogue outs of the SB2. So I'm not sure that the rationale given for closing this ticket as WONTFIX makes sense.
A fair point, Steve. I've recreated a new version of this bug against Squeezebox Touch at bug 16200.