Re: [alsa-devel] [PATCH 0/3] ALSA: snd-usb: Some small fixes to make Playback Design products work
Hi Andreas,
On 24.03.2013 02:50, Andreas Koch wrote:
At 01:01 PM 3/23/2013, Jussi Laako wrote:
On 03/22/2013 06:05 PM, Andreas Koch wrote:
The 8-bit raw format is for 2.8MHz DSD and the 16-bit format is for 5.6MHz DSD. In both cases the driver sets the sample rate to 352.8kHz on the DAC,
I see, this is different from how I've been dealing with it. Since I always use uint8 format, but instead vary the rate to 352.8/705.6/etc...
Just because it's much more straightforward form the application's perspective -> output rate is always bit rate divided by eight (=packet rate). And switch between uint8 / uint32 sample format equals to switch between DSD <-> PCM.
Since the sample rate is defined on the interface level, not on the alternate interface level, it becomes a problem to vary the sample rate. For instance, for 5.6MHz DSD a sample rate of 705.6kHz would be necessary with 8-bit data. But most likely the DAC will not support that rate for PCM. If you plug that DAC into a Mac, the Mac will automatically select 705.6kHz for PCM and then nothing will work because the DAC doesn't support that in PCM. So then, the DAC would have to define 2 complete interfaces: one for PCM and one for DSD. That increases the size of the descriptor file (which can be a problem with some hardware implementations) and increases the overhead a bit during enumeration and sample rate queries. For the hardware it is easier to bundle all into one single interface and then define alternate interfaces for PCM and DSD. Just my 2 cents from the hardware perspective.
Ok. So we could define 3 DSD formats, for 8-bit, 16-bit and 32-bit. On that three formats, arbitrary samples can be transported, and the mapping between the configured sample rate and the resulting DSD rates would be as follows (please tell me if I'm correct):
352.8kHz 705.6KHz 1411.2KHz
8-bit 2.8MHz 5.6MHz 11.2MHz 16-bit 5.6MHz 11.2MHz 32-bit 11.2MHz
So driver would mark a stream as DSD capable (8, 16, 32bit, depending on the USB descriptors), and then leave it up to the application to do the sample frequency determination according to the above table, and also as stated in the DoP document. Other drivers for more sound cards (presumable on other bus types) might follow.
I think it's ok to handle it like this, because after all, what an application sets as sample rate for the stream is the number of actual words that are transported, where as the DSD rate is referring to bits/s.
Jussi, for your application, that means that you'd have to add these 3 new formats, and teach your application that they can be used for DSD right away.
The question is whether all DSD-capable USB DACs behave correctly in order to make this logic work. Andreas?
Thanks, Daniel
Hi Daniel,
On 03/26/2013 09:58 PM, Daniel Mack wrote:
Jussi, for your application, that means that you'd have to add these 3 new formats, and teach your application that they can be used for DSD right away.
Looks good to me. This is what I was hoping for. I already kind of have the 8-bit and 32-bit, but I'll need to add the 16-bit one and make some related code cleanups to make things proper now since it's becoming official format.
I'll put this into my 3.0 release. :)
Thanks,
- Jussi
participants (2)
-
Daniel Mack
-
Jussi Laako