Bugzilla – Bug 16641
Channel Status Word not set for 24 bit in SPDIF output
Last modified: 2012-01-16 20:45:24 UTC
PROBLEM DESCRIPTION: My Cambridge Audio 840C, that I use as a DAC for my Squeezebox Touch, is not recognizing the word length of the provided SPDIF data stream from the SQB Touch. It is locking correct on the sample frequency (48 or 96 KHz) but it displays the Word Length as <=20 bits when a PCM/WAV 24/48 or 24/96 is streamed by the Squeezebox Touch. This is not Slimserver related, because when I play the same file from a USB stick using the embedded server, the problem remains. PROBABLE SOLUTION: Reading the FAQ entries on the Cambridge Audio website on a related issue, I found the possible cause: It is highly possible that not sending the word length in the SQB SPDIF Channel Status Word is causing this problem.. Technically this is/was never an issue, because 20 bit data words (padded with zeros) are/were sufficient. But because the new devices are marketed as 24 bit /96 KHz max. output devices, something have to be changed in Byte-2 of the Channel Status Word within the SPDIF protocol to resolve this "problem". Channel Status Word: byte 2: audio word length bits 0–2: Aux bits usage. This indicates how the aux bits (time slots 4–7) are used. Generally set to 000 (unused) or 001 (used for 24-bit audio data). bits 3–5: Word length. Specifies the sample size, relative to the 20- or 24-bit maximum. Can specify 0, 1, 2 or 4 missing bits. Unused bits are filled with 0, but audio processing functions such as mixing will generally fill them in with valid data without changing the effective word length. bits 6–7: Unused
Does this cause playback problems?
Hi Andy, To be honnest... I don't know. There is no way to hear the difference between a 20bit and a 24 bit word length. I have no means to determine how the Cambridge Audio reacts on missing bits in the Channel Status Word of the SPDIF protocol. The only thing I do know is that the CA can't determine the incomming word length. it displays f.i. <=20 bit @ 96KHz The FAQ on this subject on the Cambridge Audio site states: Part of the data package that is sent in the digital signal from a source device should include information about what the bit rate actually is - this 'information' is what the 840C uses to determine what is displayed on its own front panel. Often, many manufacturers do not include this information packet, or status bit, in with the digital output signal. It is the 'status bit' that requires setting or inclusion in the output device. There are different levels of status bit - some that indicate whether a file is greater or less than a certain bit rate, and some that go into more detail about what the bit rate actually is. It would appear that in certain source devices, only the SPDIF status bit that indicates whether bit depth is greater or less than 20 bits has been set. The additional status bits that indicate exact bit depth are not set and hence the SPDIF receiver (eg 740C/840C ) can only report that the bit depth is greater or less than 20/24 bits.
I also have the 840C, and would greatly appreciate this issue being addressed! Don't know how many other DACs have this kind of behavior, seems most show only the rate (44.1, 96, etc.). I returned a Boxee Box because I wasn't convinced the thing was sending more than 16 bit files out the toslink connection ... now I get the same thing with the Touch! ALTHO, I admit, the Touch is certainly a much better fit to my primary purpose in using these things, which is for 24/96 stereo audio streaming ... ;^)
*** This bug has been confirmed by popular vote. ***
Given that SB players are 24-bit anyway, why not just force the status bits to reflect reality? - no need for any complicated logic...
You may also have the option to use "pro mode" You can choose between consumer and pro with alsa pro being "AES3" and it seems to have status options that could give consistent results ? Just an idea might be stupid dissmis it it it soo ? Afiak most reciver chips ever done can handle both pro and consumer mode ? maybe someone with an absurd dac ano 1983 would have a problem ? Some hints are given directly by the alsa utilities on you linux pc. mikael@mikael:~$ iecset -h Usage: iecset [options] [cmd arg...] Options: -D device specifies the control device to use -c card specifies the card number to use (equiv. with -Dhw:#) -n number specifies the control index number (default = 0) -x dump the dump the AESx hex code for IEC958 PCM parameters -i read commands from stdin Commands: professional (common) off = consumer mode, on = professional mode audio (common) on = audio mode, off = non-audio mode rate (common) sample rate in Hz (0 = not indicated) emphasis (common) 0 = none, 1 = 50/15us, 2 = CCITT lock (prof.) off = rate unlocked, on = rate locked sbits (prof.) sample bits 2 = 20bit, 4 = 24bit, 6 = undef wordlength (prof.) 0=no, 2=22-18bit, 4=23-19bit, 5=24-20bit, 6=20-16bit category (consumer) 0-0x7f copyright (consumer) off = non-copyright, on = copyright original (consumer) off = 1st-gen, on = original mikael@mikael:~$
Would anyone be willing to work on a patch for this? If it's only cosmetic I'm not sure we would be that worried about fixing it.
This could be more than cosmetic if the DAC actually uses the word length indicator. We are assuming most will not but it would not be beyond the realms of possibility for a DAC with an 24-bit internal word length set set the least-significant 8 bits to zero when it is told to expect 16-bit data.