Re: [alsa-devel] [PATCH 2/2] alsa-lib: bring pcm.h and pcm.c in sync with the kernel list
On 04/05/2013 10:59 PM, Andreas Koch wrote:
However, they are interpreting the ASIO spec for DSD differently. They express buffer size in samples, which means that for DSD it is measured in bits.
That's how pretty much everybody, including Sony who co-authored the spec, has been interpreting it so far...
Otherwise all the latency calculations become inconsistent and need special exceptions for DSD. I agree the ASIO spec is not very clear, however it always talks about number of samples and then specifically mentions that DSD samples are _packed_ into bytes and thus all buffer sizes have to multiples of eight.
I have a hidden configuration flag to flip that either way as necessary, but default is that sizes are in _bits_.
- Jussi
On 04/05/2013 10:59 PM, Andreas Koch wrote: However, they are interpreting the ASIO spec for DSD differently. They express buffer size in samples, which means that for DSD it is measured in bits.
One more thing.. So the logic should go like this:
DSD sample -> 1-bit -> sample rates in bits per second -> buffer and latency sizes in bits.
...or...
DSD sample -> 8-bit -> sample rates in bytes per second -> buffer and latency sizes in bytes.
But please, please, don't mix bits and bytes in the API, always use only either of these.
- Jussi
On 05.04.2013 22:53, Jussi Laako wrote:
On 04/05/2013 10:59 PM, Andreas Koch wrote: However, they are interpreting the ASIO spec for DSD differently. They express buffer size in samples, which means that for DSD it is measured in bits.
One more thing.. So the logic should go like this:
DSD sample -> 1-bit -> sample rates in bits per second -> buffer and latency sizes in bits.
...or...
DSD sample -> 8-bit -> sample rates in bytes per second -> buffer and latency sizes in bytes.
But please, please, don't mix bits and bytes in the API, always use only either of these.
Well, we don't care for the ASIO spec of course, as we do not share any compatibility layer with them. So we can define whatever we think is useful and consistent.
All audio formats are specified in *bytes* for sample and buffer sizes, so we will also keep it that way for DSD. Plus, that way we do not have to fiddle with sample rate translations but always keep the hardware state in sync to the user space API. Everything will end in utter confusion at some point.
I will, however, add 'DOP' to the data type names, so it's clear that the application stack has to deal with the padding bytes.
I'll send out new patches in a minute.
Thanks, Daniel
All audio formats are specified in *bytes* for sample and buffer sizes, so we will also keep it that way for DSD.
Umm, IIRC, all the ALSA PCM API snd_pcm_*_period_size() stuff is in number of frames? (number of samples per channel) Thus size of the buffer is period size * sample size * channels (* nperiods). So if we would use 2.8 MHz as sampling rate for DSD, then buffer size would be period size * 1/8 * channels, since one sample of DSD is eight' of a byte.
And sampling rate is number of frames per second. So it is quite clear and non-confusing.
On 06.04.2013 19:52, Jussi Laako wrote:
All audio formats are specified in *bytes* for sample and buffer sizes, so we will also keep it that way for DSD.
Umm, IIRC, all the ALSA PCM API snd_pcm_*_period_size() stuff is in number of frames? (number of samples per channel)
I was talking about the SND_PCM_FORMAT_ definitions that I augmented. What they denote is bytes per sample frame, not bits.
Thus size of the buffer is period size * sample size * channels (* nperiods). So if we would use 2.8 MHz as sampling rate for DSD, then buffer size would be period size * 1/8 * channels, since one sample of DSD is eight' of a byte.
No, you would choose 1/8 of the actual sample rate, because the actual transport goes in multiple of 8 bits.
And sampling rate is number of frames per second. So it is quite clear and non-confusing.
... and one frame is also just 8 bits (or 16, for the second format). I think that matches the logic quite well.
Daniel
On 04/06/2013 08:58 PM, Daniel Mack wrote:
... and one frame is also just 8 bits (or 16, for the second format). I think that matches the logic quite well.
OK, so we agree. But what Andreas has in ASIO is sample rate at 2822400 and periods actually contain period size number of bytes and thus period size * 8 samples. While for others periods actually contain period size number of samples and thus period size / 8 bytes (for DSD). Of course DSD64 doesn't do 2822400 bytes per second. It is either 2822400 bits per second, 352800 U8 per second, 176400 U16 per second or 88200 U32 per second. This keeps real sample (bit) rate of nbits(type)*sample rate == bit rate consistent.
So for U8 type and 2822400 DSD bit rate sample rate 352800. And for U16 type 176400 sample rate. Now you can already see that for U8 type there's no overlap with any PCM hardware at least I'm aware of, but for U16 at 176400 there already is.
If we have DSD-specific sample types, the overlap is not a problem. If we don't and want to utilize UAC2 spec it matters more.
participants (2)
-
Daniel Mack -
Jussi Laako