[PATCH 1/2] alsa-lib: pcm.c: fix indentation

[PATCH 1/2] alsa-lib: pcm.c: fix indentation

[Daniel Mack]

Signed-off-by: Daniel Mack <zonque@gmail.com>
---
 src/pcm/pcm.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c
index 05737d9..2963711 100644
--- a/src/pcm/pcm.c
+++ b/src/pcm/pcm.c
@@ -1634,11 +1634,11 @@ static const char *const snd_pcm_type_names[] = {
 	PCMTYPE(LADSPA), 
 	PCMTYPE(DMIX), 
 	PCMTYPE(JACK),
-        PCMTYPE(DSNOOP),
-        PCMTYPE(IEC958),
+	PCMTYPE(DSNOOP),
+	PCMTYPE(IEC958),
 	PCMTYPE(SOFTVOL),
-        PCMTYPE(IOPLUG),
-        PCMTYPE(EXTPLUG),
+	PCMTYPE(IOPLUG),
+	PCMTYPE(EXTPLUG),
 	PCMTYPE(MMAP_EMUL),
 };
 
-- 
1.8.1.4

[PATCH 2/2] alsa-lib: bring pcm.h and pcm.c in sync with the kernel list

[Daniel Mack]

In particular, this adds definitions and descriptions for G.723 and
DSD types.

Signed-off-by: Daniel Mack <zonque@gmail.com>
---
 include/pcm.h | 14 +++++++++++++-
 src/pcm/pcm.c | 12 ++++++++++++
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/include/pcm.h b/include/pcm.h
index 2235678..ec4fb1c 100644
--- a/include/pcm.h
+++ b/include/pcm.h
@@ -199,7 +199,19 @@ typedef enum _snd_pcm_format {
 	SND_PCM_FORMAT_U18_3LE,
 	/** Unsigned 18bit Big Endian in 3bytes format */
 	SND_PCM_FORMAT_U18_3BE,
-	SND_PCM_FORMAT_LAST = SND_PCM_FORMAT_U18_3BE,
+	/* G.723 (ADPCM) 24 kbit/s, 8 samples in 3 bytes */
+	SND_PCM_FORMAT_G723_24,
+	/* G.723 (ADPCM) 24 kbit/s, 1 sample in 1 byte */
+	SND_PCM_FORMAT_G723_24_1B,
+	/* G.723 (ADPCM) 40 kbit/s, 8 samples in 3 bytes */
+	SND_PCM_FORMAT_G723_40,
+	/* G.723 (ADPCM) 40 kbit/s, 1 sample in 1 byte */
+	SND_PCM_FORMAT_G723_40_1B,
+	/* Direct Stream Digital (DSD) in 8-bit sample frames */
+	SND_PCM_FORMAT_DSD_U8,
+	/* Direct Stream Digital (DSD) in 16-bit sample frames */
+	SND_PCM_FORMAT_DSD_U16,
+	SND_PCM_FORMAT_LAST = SND_PCM_FORMAT_DSD_U16,
 
 #if __BYTE_ORDER == __LITTLE_ENDIAN
 	/** Signed 16 bit CPU endian */
diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c
index 2963711..9744060 100644
--- a/src/pcm/pcm.c
+++ b/src/pcm/pcm.c
@@ -1554,6 +1554,12 @@ static const char *const snd_pcm_format_names[] = {
 	FORMAT(S18_3BE),
 	FORMAT(U18_3LE),
 	FORMAT(U18_3BE),
+	FORMAT(G723_24),
+	FORMAT(G723_24_1B),
+	FORMAT(G723_40),
+	FORMAT(G723_40_1B),
+	FORMAT(DSD_U8),
+	FORMAT(DSD_U16),
 };
 
 static const char *const snd_pcm_format_aliases[SND_PCM_FORMAT_LAST+1] = {
@@ -1607,6 +1613,12 @@ static const char *const snd_pcm_format_descriptions[] = {
 	FORMATD(S18_3BE, "Signed 18 bit Big Endian in 3bytes"),
 	FORMATD(U18_3LE, "Unsigned 18 bit Little Endian in 3bytes"),
 	FORMATD(U18_3BE, "Unsigned 18 bit Big Endian in 3bytes"),
+	FORMATD(G723_24, "G.723 (ADPCM) 24 kbit/s, 8 samples in 3 bytes"),
+	FORMATD(G723_24_1B, "G.723 (ADPCM) 24 kbit/s, 1 sample in 1 byte"),
+	FORMATD(G723_40, "G.723 (ADPCM) 40 kbit/s, 8 samples in 3 bytes"),
+	FORMATD(G723_40_1B, "G.723 (ADPCM) 40 kbit/s, 1 sample in 1 byte"),
+	FORMATD(DSD_U8, "Direct Stream Digital (DSD), 1 byte per sample"),
+	FORMATD(DSD_U16, "Direct Stream Digital (DSD), 2 bytes per sample"),
 };
 
 static const char *const snd_pcm_type_names[] = {
-- 
1.8.1.4

Re: [PATCH 2/2] alsa-lib: bring pcm.h and pcm.c in sync with the kernel list

[Jussi Laako]

Hi,

On 03/28/2013 01:32 AM, Daniel Mack wrote:
> In particular, this adds definitions and descriptions for G.723 and
> DSD types.

Daniel,

It would be important to document the correct bit order for the DSD 
sample types to avoid confusion. There are two different conventions in 
use, oldest bit in MSB and oldest bit in LSB... (be aware that at some 
point in not too distant future someone could ask for the other one)


Andreas,

Am I right to assume that in your case it's the same as for DoP, IOW, 
oldest in MSB?


Thanks,

	- Jussi

Re: [PATCH 2/2] alsa-lib: bring pcm.h and pcm.c in sync with the kernel list

[Jussi Laako]

Hi Andreas,> Now of course, with your heroic effort in creating a 
generic driver that
> would help everyone, we have a mess. Some DACs expect little endian
> (mine and others as well) and others (all that are based on Rigisystems
> modules) big endian positions.

OK, we actually have two separate endianess issues here, but only one 
with word lengths longer than 8-bit.

We have the traditional byte order endianess and the bit order 
endianess. Of course from computer point of view order of bits in a byte 
is sort of separate issue. And now the two file formats used for DSD use 
opposite bit ordering, but being byte-based don't have the byte ordering 
issue. At worst we have four different sample format possibilities for 
word lengths longer than a byte...

Either way, application will have to be able to reshuffle the bits for 
the other format.


	- Jussi

Re: [PATCH 2/2] alsa-lib: bring pcm.h and pcm.c in sync with the kernel list

[Jussi Laako]

On 03/28/2013 09:36 AM, Jussi Laako wrote:
> OK, we actually have two separate endianess issues here, but only one
> with word lengths longer than 8-bit.

Argh... shouldn't write emails before morning coffee.

Of course I meant the problem of two is only with word lengths >8-bit. 
And only one problem for 8-bit.

Re: [PATCH 2/2] alsa-lib: bring pcm.h and pcm.c in sync with the kernel list

[Daniel Mack]

On 28.03.2013 08:36, Jussi Laako wrote:
> Either way, application will have to be able to reshuffle the bits for 
> the other format.

If you share your implementation to do that, it could eventually also
move into the 'plug' plugin in userspace, so conversion is done on the
fly as needed.


Daniel

Re: [PATCH 2/2] alsa-lib: bring pcm.h and pcm.c in sync with the kernel list

[Daniel Mack]

On 28.03.2013 05:58, Andreas Koch wrote:
> 
>>
>> Andreas,
>>
>> Am I right to assume that in your case it's the same as for DoP, 
>> IOW, oldest in MSB?
> 
> Good point - thanks for bringing it up - another can of worms.
> With Windows having a little endian philosophy we started early on 
> with the first DSD workstation by putting the oldest sample in the 
> LSB position. ASIO came along and adopted the same thing, but then 
> extended support for the opposite as well. Rigisystems (offering OEM 
> modules for USB audio) came along about a year ago and insisted that 
> there is only their way, i.e. putting the oldest bit in the MSB 
> position. I tried to explain to them that there are already hundreds 
> of products out in the market that do it differently, but that didn't 
> matter to them. The result is that now we have implementations with 
> both. Up until now that was not a huge issue, because there is no 
> generic Windows driver and every hardware manufacturer had to have a 
> custom driver.
> Now of course, with your heroic effort in creating a generic driver 
> that would help everyone, we have a mess. Some DACs expect little 
> endian (mine and others as well) and others (all that are based on 
> Rigisystems modules) big endian positions.
> 
> Since the time I had the discussions with Rigisystems I didn't have 
> any further communication with them. Maybe it is a good idea to touch 
> base with them again and find out what the latest is. I will try my 
> contact there and let you know.

Eek, what an utter mess. Just let me know what you find out. We then
need to augment the number of DSD formats, but then again, we can also
move the sample rate calculation table inside the ALSA kernel core instead.

Takashi et al - please don't apply any of these patches yet (expecpt for
the the indentation fixup) :) I guess we need some more spins on this.

Thanks,
Daniel

Re: [PATCH 2/2] alsa-lib: bring pcm.h and pcm.c in sync with the kernel list

[Daniel Mack]

Hi Andreas,

On 28.03.2013 05:58, Andreas Koch wrote:
>> Am I right to assume that in your case it's the same as for DoP, 
>> IOW, oldest in MSB?
> 
> Good point - thanks for bringing it up - another can of worms.
> With Windows having a little endian philosophy we started early on 
> with the first DSD workstation by putting the oldest sample in the 
> LSB position. ASIO came along and adopted the same thing, but then 
> extended support for the opposite as well. Rigisystems (offering OEM 
> modules for USB audio) came along about a year ago and insisted that 
> there is only their way, i.e. putting the oldest bit in the MSB 
> position. I tried to explain to them that there are already hundreds 
> of products out in the market that do it differently, but that didn't 
> matter to them. The result is that now we have implementations with 
> both. Up until now that was not a huge issue, because there is no 
> generic Windows driver and every hardware manufacturer had to have a 
> custom driver.
> Now of course, with your heroic effort in creating a generic driver 
> that would help everyone, we have a mess. Some DACs expect little 
> endian (mine and others as well) and others (all that are based on 
> Rigisystems modules) big endian positions.
> 
> Since the time I had the discussions with Rigisystems I didn't have 
> any further communication with them. Maybe it is a good idea to touch 
> base with them again and find out what the latest is. I will try my 
> contact there and let you know.

Did you hear back from them yet? Do you think we should allocate types
for Big Endian DOP formats?


Thanks,
Daniel

Re: [PATCH 2/2] alsa-lib: bring pcm.h and pcm.c in sync with the kernel list

[Jussi Laako]

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

Re: [PATCH 2/2] alsa-lib: bring pcm.h and pcm.c in sync with the kernel list

[Jussi Laako]

> 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

Re: [PATCH 2/2] alsa-lib: bring pcm.h and pcm.c in sync with the kernel list

[Daniel Mack]

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

Re: [PATCH 2/2] alsa-lib: bring pcm.h and pcm.c in sync with the kernel list

[Jussi Laako]

> 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.

Re: [PATCH 2/2] alsa-lib: bring pcm.h and pcm.c in sync with the kernel list

[Daniel Mack]

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

Re: [PATCH 2/2] alsa-lib: bring pcm.h and pcm.c in sync with the kernel list

[Jussi Laako]

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.

[PATCH 1/2] alsa-lib: pcm.c: fix indentation

[Daniel Mack]

Signed-off-by: Daniel Mack <zonque@gmail.com>
---
 src/pcm/pcm.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c
index 05737d9..2963711 100644
--- a/src/pcm/pcm.c
+++ b/src/pcm/pcm.c
@@ -1634,11 +1634,11 @@ static const char *const snd_pcm_type_names[] = {
 	PCMTYPE(LADSPA), 
 	PCMTYPE(DMIX), 
 	PCMTYPE(JACK),
-        PCMTYPE(DSNOOP),
-        PCMTYPE(IEC958),
+	PCMTYPE(DSNOOP),
+	PCMTYPE(IEC958),
 	PCMTYPE(SOFTVOL),
-        PCMTYPE(IOPLUG),
-        PCMTYPE(EXTPLUG),
+	PCMTYPE(IOPLUG),
+	PCMTYPE(EXTPLUG),
 	PCMTYPE(MMAP_EMUL),
 };
 
-- 
1.8.1.4

[PATCH 2/2] alsa-lib: bring pcm.h and pcm.c in sync with the kernel list

[Daniel Mack]

In particular, this adds definitions and descriptions for G.723 and
DSD types.

Signed-off-by: Daniel Mack <zonque@gmail.com>
---
 include/pcm.h | 14 +++++++++++++-
 src/pcm/pcm.c | 12 ++++++++++++
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/include/pcm.h b/include/pcm.h
index 2235678..fc0cfea 100644
--- a/include/pcm.h
+++ b/include/pcm.h
@@ -199,7 +199,19 @@ typedef enum _snd_pcm_format {
 	SND_PCM_FORMAT_U18_3LE,
 	/** Unsigned 18bit Big Endian in 3bytes format */
 	SND_PCM_FORMAT_U18_3BE,
-	SND_PCM_FORMAT_LAST = SND_PCM_FORMAT_U18_3BE,
+	/* G.723 (ADPCM) 24 kbit/s, 8 samples in 3 bytes */
+	SND_PCM_FORMAT_G723_24,
+	/* G.723 (ADPCM) 24 kbit/s, 1 sample in 1 byte */
+	SND_PCM_FORMAT_G723_24_1B,
+	/* G.723 (ADPCM) 40 kbit/s, 8 samples in 3 bytes */
+	SND_PCM_FORMAT_G723_40,
+	/* G.723 (ADPCM) 40 kbit/s, 1 sample in 1 byte */
+	SND_PCM_FORMAT_G723_40_1B,
+	/* Direct Stream Digital (DSD) in 1-byte samples (x8) */
+	SND_PCM_FORMAT_DSD_U8,
+	/* Direct Stream Digital (DSD) in 2-byte samples (x16) */
+	SND_PCM_FORMAT_DSD_U16_LE,
+	SND_PCM_FORMAT_LAST = SND_PCM_FORMAT_DSD_U16_LE,
 
 #if __BYTE_ORDER == __LITTLE_ENDIAN
 	/** Signed 16 bit CPU endian */
diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c
index 2963711..8d7b67d 100644
--- a/src/pcm/pcm.c
+++ b/src/pcm/pcm.c
@@ -1554,6 +1554,12 @@ static const char *const snd_pcm_format_names[] = {
 	FORMAT(S18_3BE),
 	FORMAT(U18_3LE),
 	FORMAT(U18_3BE),
+	FORMAT(G723_24),
+	FORMAT(G723_24_1B),
+	FORMAT(G723_40),
+	FORMAT(G723_40_1B),
+	FORMAT(DSD_U8),
+	FORMAT(DSD_U16_LE),
 };
 
 static const char *const snd_pcm_format_aliases[SND_PCM_FORMAT_LAST+1] = {
@@ -1607,6 +1613,12 @@ static const char *const snd_pcm_format_descriptions[] = {
 	FORMATD(S18_3BE, "Signed 18 bit Big Endian in 3bytes"),
 	FORMATD(U18_3LE, "Unsigned 18 bit Little Endian in 3bytes"),
 	FORMATD(U18_3BE, "Unsigned 18 bit Big Endian in 3bytes"),
+	FORMATD(G723_24, "G.723 (ADPCM) 24 kbit/s, 8 samples in 3 bytes"),
+	FORMATD(G723_24_1B, "G.723 (ADPCM) 24 kbit/s, 1 sample in 1 byte"),
+	FORMATD(G723_40, "G.723 (ADPCM) 40 kbit/s, 8 samples in 3 bytes"),
+	FORMATD(G723_40_1B, "G.723 (ADPCM) 40 kbit/s, 1 sample in 1 byte"),
+	FORMATD(DSD_U8,  "Direct Stream Digital, 1-byte (x8), oldest bit in MSB"),
+	FORMATD(DSD_U16_LE, "Direct Stream Digital, 2-byte (x16), little endian, oldest bits in MSB"),
 };
 
 static const char *const snd_pcm_type_names[] = {
-- 
1.8.1.4