[alsa-devel] [PATCH 0/3] ALSA: snd-usb: Some small fixes to make Playback Design products work
Daniel Mack
zonque at gmail.com
Wed Mar 27 10:48:57 CET 2013
On 27.03.2013 06:50, Andreas Koch wrote:
> Hi Daniel
>
>> 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?
>
> If I understand this correctly then your driver would send the DSD
> data in whatever format the DAC requests via its descriptors. The DSD
> rate would either control the word length (8,16,32) or the underlying
> sample rate (1x, 2x, 4x 352.8kHz). That would be the most flexible
> implementation and I don't see why any hardware implementation would
> have a problem with that.
The question is whether all DACs would assume the same DSD rate as in
the table above (ie, 8-bit, 352.8kHz == 2.8MHz DSD).
And do we actually need a 32-bit format at all or is 8 and 16 enough?
> The only potential fly in the ointment is
> that we assume that the raw data format means DSD. In other words, if
> a DAC uses raw data for any other purpose with similar wordlength
> and/or sample rate spec. then we are in trouble. The chance for that
> is small though.
As there's nothing the UAC2 spec helps us with, we have to live with
quirks for that.
Daniel
More information about the Alsa-devel
mailing list