[alsa-devel] [PATCH 0/3] ALSA: snd-usb: Some small fixes to make Playback Design products work
Thanks to Andreas, I got my hands on a Playback Design MPD-3 and hacked up some small hanges necessary to make it fully work with snd-usb.
The device reports 0x80000000 in the bmFormats field of two of three of its alternate settings, which wrongly made the driver believe it's a usual PCM endpoint (actually due to a fix-up fallback). However, bit 31 of this mask in fact denotes 'raw data'.
The effect of this issue is that in addition to the first altsetting with a bit depth of 24, the driver exposed 8-bit and 16-bit native audio formats on the raw data endpoints, which do not work as expected.
Also, those devices need a 50ms delay after switching the USB interface.
Thanks, Daniel
Daniel Mack (3): ALSA: snd-usb: handle the bmFormats field as unsigned int ALSA: snd-usb: handle raw data format of UAC2 devices ALSA: snd-usb: add delay quirk for "Playback Design" products
include/linux/usb/audio-v2.h | 2 ++ sound/usb/format.c | 20 ++++++++++++-------- sound/usb/format.h | 2 +- sound/usb/pcm.c | 7 +++++++ sound/usb/stream.c | 2 +- 5 files changed, 23 insertions(+), 10 deletions(-)
This field may use up to 32 bits, so it should be handled as unsigned int.
Signed-off-by: Daniel Mack zonque@gmail.com Reported-by: Andreas Koch andreas@akdesigninc.com --- sound/usb/format.c | 9 +++++---- sound/usb/format.h | 2 +- sound/usb/stream.c | 2 +- 3 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/sound/usb/format.c b/sound/usb/format.c index e831ee4..b30d6fb 100644 --- a/sound/usb/format.c +++ b/sound/usb/format.c @@ -43,7 +43,7 @@ */ static u64 parse_audio_format_i_type(struct snd_usb_audio *chip, struct audioformat *fp, - int format, void *_fmt, + unsigned int format, void *_fmt, int protocol) { int sample_width, sample_bytes; @@ -353,7 +353,7 @@ err: * parse the format type I and III descriptors */ static int parse_audio_format_i(struct snd_usb_audio *chip, - struct audioformat *fp, int format, + struct audioformat *fp, unsigned int format, struct uac_format_type_i_continuous_descriptor *fmt, struct usb_host_interface *iface) { @@ -473,8 +473,9 @@ static int parse_audio_format_ii(struct snd_usb_audio *chip, return ret; }
-int snd_usb_parse_audio_format(struct snd_usb_audio *chip, struct audioformat *fp, - int format, struct uac_format_type_i_continuous_descriptor *fmt, +int snd_usb_parse_audio_format(struct snd_usb_audio *chip, + struct audioformat *fp, unsigned int format, + struct uac_format_type_i_continuous_descriptor *fmt, int stream, struct usb_host_interface *iface) { int err; diff --git a/sound/usb/format.h b/sound/usb/format.h index 387924f..6f31522 100644 --- a/sound/usb/format.h +++ b/sound/usb/format.h @@ -2,7 +2,7 @@ #define __USBAUDIO_FORMAT_H
int snd_usb_parse_audio_format(struct snd_usb_audio *chip, - struct audioformat *fp, int format, + struct audioformat *fp, unsigned int format, struct uac_format_type_i_continuous_descriptor *fmt, int stream, struct usb_host_interface *iface);
diff --git a/sound/usb/stream.c b/sound/usb/stream.c index ad181d5..ad07046 100644 --- a/sound/usb/stream.c +++ b/sound/usb/stream.c @@ -463,7 +463,7 @@ int snd_usb_parse_audio_interface(struct snd_usb_audio *chip, int iface_no) struct usb_host_interface *alts; struct usb_interface_descriptor *altsd; int i, altno, err, stream; - int format = 0, num_channels = 0; + unsigned int format = 0, num_channels = 0; struct audioformat *fp = NULL; int num, protocol, clock = 0; struct uac_format_type_i_continuous_descriptor *fmt;
UAC2 compliant audio devices may announce the capability to transport raw audio data on their endpoints. Catch this and handle it as 'special' stream on the ALSA side.
Signed-off-by: Daniel Mack zonque@gmail.com Reported-by: Andreas Koch andreas@akdesigninc.com --- include/linux/usb/audio-v2.h | 2 ++ sound/usb/format.c | 11 +++++++---- 2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/include/linux/usb/audio-v2.h b/include/linux/usb/audio-v2.h index ed13053..c5f2158 100644 --- a/include/linux/usb/audio-v2.h +++ b/include/linux/usb/audio-v2.h @@ -170,6 +170,8 @@ struct uac2_as_header_descriptor { __u8 iChannelNames; } __attribute__((packed));
+#define UAC2_FORMAT_TYPE_I_RAW_DATA (1 << 31) + /* 4.10.1.2 Class-Specific AS Isochronous Audio Data Endpoint Descriptor */
struct uac2_iso_endpoint_descriptor { diff --git a/sound/usb/format.c b/sound/usb/format.c index b30d6fb..a695caf 100644 --- a/sound/usb/format.c +++ b/sound/usb/format.c @@ -47,7 +47,7 @@ static u64 parse_audio_format_i_type(struct snd_usb_audio *chip, int protocol) { int sample_width, sample_bytes; - u64 pcm_formats; + u64 pcm_formats = 0;
switch (protocol) { case UAC_VERSION_1: @@ -63,14 +63,17 @@ static u64 parse_audio_format_i_type(struct snd_usb_audio *chip, struct uac_format_type_i_ext_descriptor *fmt = _fmt; sample_width = fmt->bBitResolution; sample_bytes = fmt->bSubslotSize; + + if (format & UAC2_FORMAT_TYPE_I_RAW_DATA) + pcm_formats |= SNDRV_PCM_FMTBIT_SPECIAL; + format <<= 1; break; } }
- pcm_formats = 0; - - if (format == 0 || format == (1 << UAC_FORMAT_TYPE_I_UNDEFINED)) { + if ((pcm_formats == 0) && + (format == 0 || format == (1 << UAC_FORMAT_TYPE_I_UNDEFINED))) { /* some devices don't define this correctly... */ snd_printdd(KERN_INFO "%d:%u:%d : format type 0 is detected, processed as PCM\n", chip->dev->devnum, fp->iface, fp->altsetting);
"Playback Design" products need a 50ms delay after setting the USB interface.
Signed-off-by: Daniel Mack zonque@gmail.com Reported-by: Andreas Koch andreas@akdesigninc.com --- sound/usb/pcm.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index f94397b..c263991 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -350,6 +350,13 @@ static int set_format(struct snd_usb_substream *subs, struct audioformat *fmt) fmt->iface, fmt->altsetting); subs->interface = fmt->iface; subs->altset_idx = fmt->altset_idx; + + /* + * "Playback Design" products need a 50ms delay after setting the + * USB interface. + */ + if (le16_to_cpu(dev->descriptor.idVendor) == 0x23ba) + mdelay(50); }
subs->data_endpoint = snd_usb_add_endpoint(subs->stream->chip,
At Sun, 17 Mar 2013 20:07:23 +0800, Daniel Mack wrote:
Thanks to Andreas, I got my hands on a Playback Design MPD-3 and hacked up some small hanges necessary to make it fully work with snd-usb.
The device reports 0x80000000 in the bmFormats field of two of three of its alternate settings, which wrongly made the driver believe it's a usual PCM endpoint (actually due to a fix-up fallback). However, bit 31 of this mask in fact denotes 'raw data'.
The effect of this issue is that in addition to the first altsetting with a bit depth of 24, the driver exposed 8-bit and 16-bit native audio formats on the raw data endpoints, which do not work as expected.
Also, those devices need a 50ms delay after switching the USB interface.
Thanks, applied to for-next branch.
The remaining question is which PCM format is suitable for the raw data. SND_PCM_FORMAT_SPECIAL should be OK, it won't regress at least, as no apps support this format.
Takashi
Thanks, Daniel
Daniel Mack (3): ALSA: snd-usb: handle the bmFormats field as unsigned int ALSA: snd-usb: handle raw data format of UAC2 devices ALSA: snd-usb: add delay quirk for "Playback Design" products
include/linux/usb/audio-v2.h | 2 ++ sound/usb/format.c | 20 ++++++++++++-------- sound/usb/format.h | 2 +- sound/usb/pcm.c | 7 +++++++ sound/usb/stream.c | 2 +- 5 files changed, 23 insertions(+), 10 deletions(-)
-- 1.7.10.4
On 18.03.2013 10:07, Takashi Iwai wrote:
At Sun, 17 Mar 2013 20:07:23 +0800, Daniel Mack wrote:
Thanks to Andreas, I got my hands on a Playback Design MPD-3 and hacked up some small hanges necessary to make it fully work with snd-usb.
The device reports 0x80000000 in the bmFormats field of two of three of its alternate settings, which wrongly made the driver believe it's a usual PCM endpoint (actually due to a fix-up fallback). However, bit 31 of this mask in fact denotes 'raw data'.
The effect of this issue is that in addition to the first altsetting with a bit depth of 24, the driver exposed 8-bit and 16-bit native audio formats on the raw data endpoints, which do not work as expected.
Also, those devices need a 50ms delay after switching the USB interface.
Thanks, applied to for-next branch.
The remaining question is which PCM format is suitable for the raw data. SND_PCM_FORMAT_SPECIAL should be OK, it won't regress at least, as no apps support this format.
Yes, I thought about that for a while as well. In fact, the data format the device supports on these altsettings is "DSD", but that doesn't have a defined value in the UAC2 spec (and strictly speaking, DSD is not even PCM).
So when a device is as unspecific as 'raw data', there's not much we can do about that except for exposing the same level of uncertainty down to the apps, right?
Thanks, Daniel
At Mon, 18 Mar 2013 10:15:44 +0100, Daniel Mack wrote:
On 18.03.2013 10:07, Takashi Iwai wrote:
At Sun, 17 Mar 2013 20:07:23 +0800, Daniel Mack wrote:
Thanks to Andreas, I got my hands on a Playback Design MPD-3 and hacked up some small hanges necessary to make it fully work with snd-usb.
The device reports 0x80000000 in the bmFormats field of two of three of its alternate settings, which wrongly made the driver believe it's a usual PCM endpoint (actually due to a fix-up fallback). However, bit 31 of this mask in fact denotes 'raw data'.
The effect of this issue is that in addition to the first altsetting with a bit depth of 24, the driver exposed 8-bit and 16-bit native audio formats on the raw data endpoints, which do not work as expected.
Also, those devices need a 50ms delay after switching the USB interface.
Thanks, applied to for-next branch.
The remaining question is which PCM format is suitable for the raw data. SND_PCM_FORMAT_SPECIAL should be OK, it won't regress at least, as no apps support this format.
Yes, I thought about that for a while as well. In fact, the data format the device supports on these altsettings is "DSD", but that doesn't have a defined value in the UAC2 spec (and strictly speaking, DSD is not even PCM).
So when a device is as unspecific as 'raw data', there's not much we can do about that except for exposing the same level of uncertainty down to the apps, right?
Yes. We can add a new format SND_PCM_FORMAT_RAW, but it's not much better than SND_PCM_FORMAT_SPECIAL after all :)
Takashi
On 18.03.2013 10:30, Takashi Iwai wrote:
At Mon, 18 Mar 2013 10:15:44 +0100, Daniel Mack wrote:
On 18.03.2013 10:07, Takashi Iwai wrote:
At Sun, 17 Mar 2013 20:07:23 +0800, Daniel Mack wrote:
Thanks to Andreas, I got my hands on a Playback Design MPD-3 and hacked up some small hanges necessary to make it fully work with snd-usb.
The device reports 0x80000000 in the bmFormats field of two of three of its alternate settings, which wrongly made the driver believe it's a usual PCM endpoint (actually due to a fix-up fallback). However, bit 31 of this mask in fact denotes 'raw data'.
The effect of this issue is that in addition to the first altsetting with a bit depth of 24, the driver exposed 8-bit and 16-bit native audio formats on the raw data endpoints, which do not work as expected.
Also, those devices need a 50ms delay after switching the USB interface.
Thanks, applied to for-next branch.
The remaining question is which PCM format is suitable for the raw data. SND_PCM_FORMAT_SPECIAL should be OK, it won't regress at least, as no apps support this format.
Yes, I thought about that for a while as well. In fact, the data format the device supports on these altsettings is "DSD", but that doesn't have a defined value in the UAC2 spec (and strictly speaking, DSD is not even PCM).
So when a device is as unspecific as 'raw data', there's not much we can do about that except for exposing the same level of uncertainty down to the apps, right?
Yes. We can add a new format SND_PCM_FORMAT_RAW, but it's not much better than SND_PCM_FORMAT_SPECIAL after all :)
Yes. If at all, we should add a SND_PCM_FORMAT_DSD, and a quirk for that device. But given that there is no application for DSD in userspace either, we probably don't need to care.
Thanks, Daniel
On 03/18/2013 06:49 AM, Daniel Mack wrote:
Yes, I thought about that for a while as well. In fact, the data format the device supports on these altsettings is "DSD", but that doesn't have a defined value in the UAC2 spec (and strictly speaking, DSD is not even PCM).
So when a device is as unspecific as 'raw data', there's not much we can do about that except for exposing the same level of uncertainty down to the apps, right?
Yes. We can add a new format SND_PCM_FORMAT_RAW, but it's not much better than SND_PCM_FORMAT_SPECIAL after all :)
Yes. If at all, we should add a SND_PCM_FORMAT_DSD, and a quirk for that device. But given that there is no application for DSD in userspace either, we probably don't need to care.
+1
However, more and more applications are wanting to send non-linear PCM data through ALSA. So, we probably /do/ need to care.
-gabriel
At Mon, 18 Mar 2013 19:51:09 -0700, Gabriel M. Beddingfield wrote:
On 03/18/2013 06:49 AM, Daniel Mack wrote:
Yes, I thought about that for a while as well. In fact, the data format the device supports on these altsettings is "DSD", but that doesn't have a defined value in the UAC2 spec (and strictly speaking, DSD is not even PCM).
So when a device is as unspecific as 'raw data', there's not much we can do about that except for exposing the same level of uncertainty down to the apps, right?
Yes. We can add a new format SND_PCM_FORMAT_RAW, but it's not much better than SND_PCM_FORMAT_SPECIAL after all :)
Yes. If at all, we should add a SND_PCM_FORMAT_DSD, and a quirk for that device. But given that there is no application for DSD in userspace either, we probably don't need to care.
+1
However, more and more applications are wanting to send non-linear PCM data through ALSA. So, we probably /do/ need to care.
It depends. DSD would be still likely feasible to be sent over a PCM device, as it's an audio stream after all, but most of other non-audio data wouldn't fit with the "PCM" device.
Takashi
On 03/18/2013 03:49 PM, Daniel Mack wrote:
Yes. If at all, we should add a SND_PCM_FORMAT_DSD, and a quirk for that device. But given that there is no application for DSD in userspace either, we probably don't need to care.
Yes there is? At least my application. And I'd be happy to support any custom format created for the purpose... :)
(http://www.signalyst.com/consumer.html for those who are interested)
I would propose to create custom 8-bit sample formats for DSD purposes, similar to the ASIO formats. Practically two main ones, byte with oldest bit in MSB and byte with oldest bit in LSB. And maybe the "DSD-wide" one which is 8-bit DSD sample.
- Jussi
Hi Jussi, Hi Andreas,
On 21.03.2013 22:21, Jussi Laako wrote:
On 03/18/2013 03:49 PM, Daniel Mack wrote:
Yes. If at all, we should add a SND_PCM_FORMAT_DSD, and a quirk for that device. But given that there is no application for DSD in userspace either, we probably don't need to care.
Yes there is? At least my application. And I'd be happy to support any custom format created for the purpose... :)
Ah, interesting. So what *are* you using right now for your transport in userspace? Is your application abusing standard PCM interfaces that are 'known' to be in fact DSD? How do other DACs expose their interfaces in the Linux world, and which ones did you test your application with?
If there's actual need for a new SND_PCM_FORMAT, it would be easy to patch it through all the layers down to userspace.
I would propose to create custom 8-bit sample formats for DSD purposes, similar to the ASIO formats. Practically two main ones, byte with oldest bit in MSB and byte with oldest bit in LSB. And maybe the "DSD-wide" one which is 8-bit DSD sample.
Andreas, which modes does the MPD-3 accept exactly on its two 'raw data' interfaces? The only hint I have is that one of it is 8-bit and the other is 16-bit, but given the lack of a proper test setup for this format, I can't currently test anything.
Thanks, Daniel
On 03/22/2013 10:11 AM, Daniel Mack wrote:
Ah, interesting. So what *are* you using right now for your transport in userspace? Is your application abusing standard PCM interfaces that are 'known' to be in fact DSD? How do other DACs expose their interfaces in the Linux world, and which ones did you test your application with?
Yes, it's abuse of PCM (hw) interface, I'm using the DoP specification as referred to in another post. All the DSD DACs that currently work with Linux support this. Quite many at the moment in fact and more coming all the time.
There's at least devices from Mytek, Fostex, Benchmark and Sonore/exD that work with this setup. And I believe also Chord, but I haven't got chance to test it yet.
Mytek has a vendor specific interface (RigiSystems USBPAL) that could utilize a separate raw DSD sample format.
Plus I have some of my own experiments implementing DSD on an ARM based SoC where there's no need use DoP, but now I need to use custom hack for the raw data. Thus sooner there's some officially defined ALSA formats, less likely it becomes fragmented set of different incompatible hacks. That would be a headache and nightmare for application developers.
- Jussi
Hi Jussi,
On 22.03.2013 20:37, Jussi Laako wrote:
On 03/22/2013 10:11 AM, Daniel Mack wrote:
Ah, interesting. So what *are* you using right now for your transport in userspace? Is your application abusing standard PCM interfaces that are 'known' to be in fact DSD? How do other DACs expose their interfaces in the Linux world, and which ones did you test your application with?
Yes, it's abuse of PCM (hw) interface, I'm using the DoP specification as referred to in another post.
It's really new to me that there are active users for this sample format, and we should clean up the mess by cleanly marking such streams correctly in the drivers. But I'm still not sure about the current situation in terms of hardware support. So let's shed some light ...
All the DSD DACs that currently work with Linux support this. Quite many at the moment in fact and more coming all the time.
Ok, but how do you know about which interfaces are capable of handling that? Are you maintaining a white list?
And does that mean these devices are also wrongly believed to have additional PCM interfaces? IOW: do they only work as DSD, breaking all applications that believe that they can use all devices that expose a PCM interface?
Can you show the contents of /proc/asound/cardX/stream0 for such a card maybe?
There's at least devices from Mytek, Fostex, Benchmark and Sonore/exD that work with this setup. And I believe also Chord, but I haven't got chance to test it yet.
Can you provide the output of "lsusb -v" for any of these?
Mytek has a vendor specific interface (RigiSystems USBPAL) that could utilize a separate raw DSD sample format.
Plus I have some of my own experiments implementing DSD on an ARM based SoC where there's no need use DoP, but now I need to use custom hack for the raw data. Thus sooner there's some officially defined ALSA formats, less likely it becomes fragmented set of different incompatible hacks. That would be a headache and nightmare for application developers.
I'm afraid that adding a DSD format and teaching the driver quirks for interfaces that are known to support DSD would break applications that already expect to see a usual PCM interface.
To be precise: which SND_PCM_FORMAT_* does your application accept, and what happens if it sees SND_PCM_FORMAT_SPECIAL?
As for the driver, I would not go any further than marking the streams as DSD, without touching the payload. The marker bytes as described in the DoP document could be handled by some sort of libasound convenience function maybe though.
Daniel
Hi Daniel,
On 03/23/2013 01:31 PM, Daniel Mack wrote:
Ok, but how do you know about which interfaces are capable of handling that? Are you maintaining a white list?
It's all up to user configuration, just an option in GUI for it. There are still some devices where the support depends on firmware version (support was introduced as firmware upgrade) so white listing is not so feasible always. But the situation is getting better. However I don't want to maintain a white list of vendor/device id's inside my application. Also the same format works over S/PDIF or AES/EBU just fine (with dual-wire up to DSD128). So automatic detection is not always possible anyway.
However I'm hoping to get the relevant information through the audio API in future for all possible interfaces (IOW not S/PDIF or AES/EBU, but things like USB, Firewire, PCI(e) and ASoC). Since there many DAC chips that have support for DSD it makes sense.
And does that mean these devices are also wrongly believed to have additional PCM interfaces? IOW: do they only work as DSD, breaking all applications that believe that they can use all devices that expose a PCM interface?
So far all devices have been supporting also PCM, but support for DSD128 is already a problem. Since with DoP it would require 352.8k PCM sample rate support, but some devices can do PCM only up to 192 while being able to support DSD128. Currently there's no way to figure out such limitations through ALSA (unlike ASIO where sampling rate enumeration is completely separate for PCM and DSD). So application would assume that also 352.8 PCM is available.
Can you show the contents of /proc/asound/cardX/stream0 for such a card maybe? Can you provide the output of "lsusb -v" for any of these?
There's nothing related to DSD there, because DoP is implemented in an FPGA behind the audio interface. Most common is the XMOS UAC2 implementation. Just normal asynchronous UAC2.
For the rest it's device class "vendor specific".
I'm afraid that adding a DSD format and teaching the driver quirks for interfaces that are known to support DSD would break applications that already expect to see a usual PCM interface.
Currently most interfaces support usual PCM, but in addition they support also DSD. So they have two native sample formats, but only one USB format. Except again the vendor specific ones where there tend to be two wire formats, like 3-byte 24-bit and byte stream for DSD.
To be precise: which SND_PCM_FORMAT_* does your application accept, and what happens if it sees SND_PCM_FORMAT_SPECIAL?
For PCM: SND_PCM_FORMAT_S16_LE SND_PCM_FORMAT_S16_BE SND_PCM_FORMAT_S24_LE SND_PCM_FORMAT_S24_BE SND_PCM_FORMAT_S32_LE SND_PCM_FORMAT_S32_BE SND_PCM_FORMAT_S18_3LE SND_PCM_FORMAT_S20_3LE SND_PCM_FORMAT_S24_3LE SND_PCM_FORMAT_S18_3BE SND_PCM_FORMAT_S20_3BE SND_PCM_FORMAT_S24_3BE SND_PCM_FORMAT_FLOAT_LE SND_PCM_FORMAT_FLOAT_BE SND_PCM_FORMAT_FLOAT64_LE SND_PCM_FORMAT_FLOAT64_BE
For DSD: SND_PCM_FORMAT_S8 SND_PCM_FORMAT_U8 SND_PCM_FORMAT_S24_LE SND_PCM_FORMAT_U24_LE SND_PCM_FORMAT_S24_BE SND_PCM_FORMAT_U24_BE SND_PCM_FORMAT_S32_LE SND_PCM_FORMAT_U32_LE SND_PCM_FORMAT_S32_BE SND_PCM_FORMAT_U32_BE SND_PCM_FORMAT_S24_3LE SND_PCM_FORMAT_U24_3LE SND_PCM_FORMAT_S24_3BE SND_PCM_FORMAT_U24_3BE
I'm currently using SND_PCM_FORMAT_U8 at 352800 for my raw DSD custom hacks, because it won't overlap with any real world PCM hardware... For DoP devices there are at least SND_PCM_FORMAT_S32_LE and SND_PCM_FORMAT_S24_3LE in use. XMOS uses the former one, IIRC Mytek with the TCAT Dice FW chipset uses the latter one (and the USB2 is vendor specific class).
I don't support SND_PCM_FORMAT_SPECIAL.
As for the driver, I would not go any further than marking the streams as DSD, without touching the payload. The marker bytes as described in the DoP document could be handled by some sort of libasound convenience function maybe though.
OK, then I would most likely keep the payload packing as it is already...
- Jussi
On 03/18/2013 02:07 AM, Takashi Iwai wrote:
The remaining question is which PCM format is suitable for the raw data. SND_PCM_FORMAT_SPECIAL should be OK, it won't regress at least, as no apps support this format.
I got the impression that SND_PCM_FORMAT_SPECIAL was there for appication-specific/device-specific hacks. I.e. it's a non-format that allows passing raw data through the system. If so, is it appropriate for a main-line driver?
-gabriel
At Mon, 18 Mar 2013 19:37:51 -0700, Gabriel M. Beddingfield wrote:
On 03/18/2013 02:07 AM, Takashi Iwai wrote:
The remaining question is which PCM format is suitable for the raw data. SND_PCM_FORMAT_SPECIAL should be OK, it won't regress at least, as no apps support this format.
I got the impression that SND_PCM_FORMAT_SPECIAL was there for appication-specific/device-specific hacks. I.e. it's a non-format that allows passing raw data through the system. If so, is it appropriate for a main-line driver?
It allows everything, but it also means there is no specification.
Takashi
participants (4)
-
Daniel Mack -
Gabriel M. Beddingfield -
Jussi Laako -
Takashi Iwai