Async USB Dac Experiments - testers wanted...

[JohnSwenson]

I've updated the Usb Audio Output applet to hopefully parse these values and set the right bitdepth for 16 bit dacs. Please try and report back.

I've tried USB audio 0.3 (I hope that's the right one) and it still doesn't work with my 2706 based DAC. It just continuously reboots. My guess is that both jive_alsa process die and the watchdog kicks in. Because of the way the USB DAC gets setup it wind up as card 2 which causes the effects jive_alsa to die and the music one still has problems. I need to try this with my udev setup which guarantees that all internal interfaces show up with their usual card numbers no matter whether there is a USB DAC or not. That should at least prevent it from crashing the processor. (or using TT3.0 to turn off the watchdog).

John S.

[Triode]

I've tried USB audio 0.3 (I hope that's the right one) and it still doesn't work with my 2706 based DAC. It just continuously reboots. My guess is that both jive_alsa process die and the watchdog kicks in. Because of the way the USB DAC gets setup it wind up as card 2 which causes the effects jive_alsa to die and the music one still has problems. I need to try this with my udev setup which guarantees that all internal interfaces show up with their usual card numbers no matter whether there is a USB DAC or not. That should at least prevent it from crashing the processor. (or using TT3.0 to turn off the watchdog).

John S.

Hum - can you check what got written to the settings file to see if it looks right? I would expect it to work by setting the device name directly as it should remove the card number problem, but it needs jive_alsa to open the device with settings which work - else you get the problem you have seen.

[lovejoy]

I'm running USB audio 0.3 with kernel #1 into my Audiolab 8200CDQ and it is faultless. In fact, it's the most enjoyment I've ever got from my Squeezebox Touch and that's including having used the TT3.0 mods. I've not tried putting the mods back in place yet as I'm enjoying it very much as it is.

Using kernel #2 is giving me clicks and pops every couple of seconds, so I've stuck with kernel 1 for the time being until the USB2.0 hub I've ordered arrives.

Many thanks to all involved on getting this working. It's also a major benefit to be able to use the CDQ's remote to control track skipping, play and pause. Nice work.

[tufty]

Many thanks for your work on this... I have been patiently waiting for a breakthrough and I really appreciate your perseverance.

I'm using an Audiolab 8200CDQ. With Kernel #1, no hub, sounds great so far.

I had TT3.0 installed with Logitech priorities and buffersize of 20000... I did not take it off first, and it doesn't appear to be interfering. Is it actually doing anything when playing out on USB?

Too soon for me to do a critical appraisal of the sound; I don't have golden ears, so I shall just be listening for a few days.

Curious:

1) On regular CD FLAC rips, they read as 44.1k and 16-bit on CDQ

2) ...unless I am using ReplayGain adjustment, in which case it will display as 22-bit or 23-bit depending on how aggressively it is being volume-adjusted.

3) 48k 24-bit material I have always says 24-bit regardless of ReplayGain setting.

Probably makes sense but I was expecting it to pad to 24-bit regardless.

So I have a question: is this definitely using async USB? Does this mean that jitter is essentially restricted to that in the DAC itself?

Thanks again.

[Triode]

I had TT3.0 installed with Logitech priorities and buffersize of 20000... I did not take it off first, and it doesn't appear to be interfering. Is it actually doing anything when playing out on USB?

Yes the TT priorisation will intefer as it overrides a priority change the USB applet makes to ensure the Usb irq process is real time priority (it is not by default or in the TT mods as its not expected to be used for audio). Buffer tuning should not matter in terms of dropouts as long as the priority is set. Though YMMV in terms of whether you detect audio difference - in which case try my bind test applet too...

1) On regular CD FLAC rips, they read as 44.1k and 16-bit on CDQ

2) ...unless I am using ReplayGain adjustment, in which case it will display as 22-bit or 23-bit depending on how aggressively it is being volume-adjusted.

3) 48k 24-bit material I have always says 24-bit regardless of ReplayGain setting.

This is down to the audiolab code (well lakewests's usb code - suggest you ask in more detail on pinkfish). My understanding is that it will indicate the bit depth based on whether it sees data in the bits - so although 24 bit audio is send from Touch if its from a CD and has no processing then you will see it as 16 bit. If you have RG enabled then squeezeplay is doing some processing and so there may be more bits. If you use a lossy codec you probably also see more bits as the codec in Touch is outputting 24 bits.

And as far as jitter - the theory with async usb is that the clock is generated in the dac. As JohnW would say first order impact of jitter is removed, but there's still scope for 2nd order things to mean noise/RF couples from the SBT to the dac. You could try a usb issolator to reduce this.

[MWelschenbach]

I can happily confirm that Kernel #2 plays 24/96 connected to 8200CDQ via USB 2.0 Hub without any clicks. Sound is very nice, at least as good as via coax. Next I will try to install TT 3.0 additionally.

Triode, John, thank you very much for your effort,
Michael

[warpian]

Triode,

Thanks for advancing this issue.

I have ordered an Audiophilleo #1 and will hook it up to the SBT with your Kernel #2. The Audiophilleo comes with a small oled screen that provides quite some diagnostic info. Will report back here when it arrives (sometime next week).

I'll first try without an extra hub and take it from there.

regards,
Tom

[Triode]

I have ordered an Audiophilleo #1 and will hook it up to the SBT with your Kernel #2. The Audiophilleo comes with a small oled screen that provides quite some diagnostic info. Will report back here when it arrives (sometime next week).

That looks to be a usb 2 dac - i.e. high speed. I don't think the current kernels will support that. If it can be forced to operate as a usb 1 dac then I suspect it will work. Otherwise it will probably need some more kernel updates.

[MWelschenbach]

After some struggeling with the installation process kernel #2 works nicely with Soundcheck's TT 3.0. However, as John Swenson already mentioned in an earlier post, it is necessary to disable the priority mod by editing the file /etc/init.d/rcS.local. In order to play files with 24bit/96khz without crackles and interrupts I had also to increase the buffer to 20.000 (TT command tt -b 20000). SQ is sweet.

Michael

[warpian]

That looks to be a usb 2 dac - i.e. high speed. I don't think the current kernels will support that. If it can be forced to operate as a usb 1 dac then I suspect it will work. Otherwise it will probably need some more kernel updates.

The Audiophilleo is a USB to SPDIF converter which employs USB audio class 2 asynchronous communication. I think it is based on the XMOS USB chip. It does not house a DAC. The target is a Wadia PowerDAC 151. The Wadia actually has USB input which operates in adaptive isochronous mode.

I guess I could test a direct USB connection from the SBT to the Wadia for you, but I am not planning on actually using it as I dont think this will sound better compared to using the SBT SPDIF out to the Wadia. I already did some extensive tests and I am confident a good asynchronous USB implementation with SPDIF out will give better results. Hence the order for the Audiophilleo.

I am planning to connect the Audiophilleo to my Ubuntu desktop. It would be a nice bonus if I could make it work straight from a SBT, but I guess that involves updating the USB driver on the Touch. Some time ago I had read that this upgrade is not easy to accomplish?

regards,
Tom