[alsa-devel] USB audio devices on Audio 4DJ and similar
Hi Daniel and Alsa folks,
At present I am involved with resolving some issues that have arisen from people using the Audio 4DJ interface with Portaudio, and I hoped it would be OK to check a few Alsa details with you? Unfortunately I have limited experience of USB audio.
Apparently the 4 audio inputs/outputs appear as 2 stereo sub-devices on the first device, rather than a single 4-channel device - is this correct?
Assuming that is correct, does that arise as a result of the intrinsic nature of the interface, or is it by developer choice in the driver (for example so that it can be opened as 2 stereo streams)? Is there (or could there be) a way to change this, eg by module option or udev rule? I notice in the source #define CHANNELS_PER_STREAM 2
Is there a way at present that the device can be accessed as a single 4-channel stream other than by creating a custom ~asoundrc with a pcm definition using 'multi' to join the 2 stereo streams?
I don't see any USB audio units having files in /usr/share/alsa/cards; is it not relevant, not normally necessary or something no-one has got round to writing?
I appreciate any clarification you can bring.
Regards
Alan
Hi Alan,
On 06.04.2012 23:09, Alan Horstmann wrote:
At present I am involved with resolving some issues that have arisen from people using the Audio 4DJ interface with Portaudio, and I hoped it would be OK to check a few Alsa details with you? Unfortunately I have limited experience of USB audio.
What are those issues? Can you elaborate?
Apparently the 4 audio inputs/outputs appear as 2 stereo sub-devices on the first device, rather than a single 4-channel device - is this correct?
Yes.
Assuming that is correct, does that arise as a result of the intrinsic nature of the interface, or is it by developer choice in the driver (for example so that it can be opened as 2 stereo streams)? Is there (or could there be) a way to change this, eg by module option or udev rule? I notice in the source #define CHANNELS_PER_STREAM 2
The device itself implements 4 audio channels which are synced to each other. In other words: the hardware is not able to only enable one of them and leave the other ones paused or set sample rates individually.
When I implemented the driver, it seem most logical to follow the way the device denotes it channels though. The documentation and silk screen presents them as pairs of stereo, and so the driver does the same thing.
Is there a way at present that the device can be accessed as a single 4-channel stream other than by creating a custom ~asoundrc with a pcm definition using 'multi' to join the 2 stereo streams?
No, you would need to join them in software. But as all inputs and outputs share a single clock domain, there won't be any drift between them that need special attention.
I don't see any USB audio units having files in /usr/share/alsa/cards; is it not relevant, not normally necessary or something no-one has got round to writing?
For this particular device, there wasn't any need yet.
Daniel
Hi Daniel,
Thanks for your helpful replies; responses below.
On Sunday 08 April 2012 15:12, Daniel Mack wrote:
On 06.04.2012 23:09, Alan Horstmann wrote:
At present I am involved with resolving some issues that have arisen from people using the Audio 4DJ interface with Portaudio, and I hoped it would be OK to check a few Alsa details with you? Unfortunately I have limited experience of USB audio.
What are those issues? Can you elaborate?
These are essentially issues in the way Portaudio interfaces; I am not suggesting driver bugs etc, but in summary:
a) The Audio 4DJ uses fixed _BE format, almost uniquely AFAICT from grepping driver source tree. Portaudio at present requests formats in the host platform endianness - so on a x86 PC an acceptable format is not available from the 'hw' device. Users seem reluctant to use 'plughw'.
b) Subdevices are not enumerated by Portaudio at present, and so only 2 of the 4 channels can be accessed. If the unit had presented a single 4-channel device all the channels would have been available.
The device itself implements 4 audio channels which are synced to each other. In other words: the hardware is not able to only enable one of them and leave the other ones paused or set sample rates individually.
When I implemented the driver, it seem most logical to follow the way the device denotes it channels though. The documentation and silk screen presents them as pairs of stereo, and so the driver does the same thing.
I am just interested whether you think it would be possible for the driver to be modified to support a single 4-ch device, perhaps through a module option?
I don't see any USB audio units having files in /usr/share/alsa/cards; is it not relevant, not normally necessary or something no-one has got round to writing?
For this particular device, there wasn't any need yet.
I couldn't see any USB cards there - is that probably correct?
Regards
Alan
Hi Alan,
On 11.04.2012 12:59, Alan Horstmann wrote:
Thanks for your helpful replies; responses below.
On Sunday 08 April 2012 15:12, Daniel Mack wrote:
On 06.04.2012 23:09, Alan Horstmann wrote:
At present I am involved with resolving some issues that have arisen from people using the Audio 4DJ interface with Portaudio, and I hoped it would be OK to check a few Alsa details with you? Unfortunately I have limited experience of USB audio.
What are those issues? Can you elaborate?
These are essentially issues in the way Portaudio interfaces; I am not suggesting driver bugs etc, but in summary:
a) The Audio 4DJ uses fixed _BE format, almost uniquely AFAICT from grepping driver source tree. Portaudio at present requests formats in the host platform endianness - so on a x86 PC an acceptable format is not available from the 'hw' device. Users seem reluctant to use 'plughw'.
Erm. Class compliant USB cards speak _LE formats only, and I'm not aware of any hardware that is able to switch endianess on a run-time configuration base. Does that mean PortAudio is unable to feed these cards on BE hosts like PowerPC? Does the sound output endianess always have to match the audio stream format? I certainly doubt that.
_From what I know, PortAudio is just a thin layer on top of ALSA and other sound APIs to ease the pain of cross-platform development of audio applications, right? What's wrong with letting ALSA convert the samples for you then?
b) Subdevices are not enumerated by Portaudio at present, and so only 2 of the 4 channels can be accessed. If the unit had presented a single 4-channel device all the channels would have been available.
Ok, I see your problem, but certainly, PortAudio is the place to get this fixed, not the driver.
The device itself implements 4 audio channels which are synced to each other. In other words: the hardware is not able to only enable one of them and leave the other ones paused or set sample rates individually.
When I implemented the driver, it seem most logical to follow the way the device denotes it channels though. The documentation and silk screen presents them as pairs of stereo, and so the driver does the same thing.
I am just interested whether you think it would be possible for the driver to be modified to support a single 4-ch device, perhaps through a module option?
Technically, it would certainly. But the problem is that there are quite a number of applications out there using these devices and making their assumptions about the implementation as it stands. So we won't accept a patch that changes the behaviour of these cards for all users.
So clearly, the issues you're seeing are due to missing features in PortAudio, and it should be fairly easy to add them there.
Daniel
On 11.04.2012 17:17, Daniel Mack wrote:
Erm. Class compliant USB cards speak _LE formats only, and I'm not aware of any hardware that is able to switch endianess on a run-time configuration base. Does that mean PortAudio is unable to feed these cards on BE hosts like PowerPC? Does the sound output endianess always have to match the audio stream format?
That should of course read: "Does the host endianess always have to match the audio stream format?"
Hi again Daniel,
On Wednesday 11 April 2012 16:17, Daniel Mack wrote:
On 11.04.2012 12:59, Alan Horstmann wrote:
These are essentially issues in the way Portaudio interfaces; I am not suggesting driver bugs etc, but in summary:
a) The Audio 4DJ uses fixed _BE format, almost uniquely AFAICT from grepping driver source tree. Portaudio at present requests formats in the host platform endianness - so on a x86 PC an acceptable format is not available from the 'hw' device. Users seem reluctant to use 'plughw'.
Erm. Class compliant USB cards speak _LE formats only, and I'm not aware of any hardware that is able to switch endianess on a run-time configuration base.
Are you referring to USB cards? It looked to me like several PCI cards listed _BE and _LE variants of some formats in the driver?
Does that mean PortAudio is unable to feed these cards on BE hosts like PowerPC? Does the host endianess always have to match the audio stream format? I certainly doubt that.
Surprisingly, when using the hw device, I think that would be the case at present.
From what I know, PortAudio is just a thin layer on top of ALSA and other sound APIs to ease the pain of cross-platform development of audio applications, right? What's wrong with letting ALSA convert the samples for you then?
That has been my perspective too, to use 'plughw' but some audio users believe the plug layer will necessarily give worse latency etc, and always want to get "as close as possible to the hardware".
b) Subdevices are not enumerated by Portaudio at present, and so only 2 of the 4 channels can be accessed. If the unit had presented a single 4-channel device all the channels would have been available.
Ok, I see your problem, but certainly, PortAudio is the place to get this fixed, not the driver.
Yes, but listing all subdevices does have it's own problems, as some cards have large numbers of them, for some reason.
I am just interested whether you think it would be possible for the driver to be modified to support a single 4-ch device, perhaps through a module option?
Technically, it would certainly. But the problem is that there are quite a number of applications out there using these devices and making their assumptions about the implementation as it stands. So we won't accept a patch that changes the behaviour of these cards for all users.
So clearly, the issues you're seeing are due to missing features in PortAudio, and it should be fairly easy to add them there.
Well, I don't think it will be easy in fact, due to the constraints of a multi-platform API that is largely shaped by platforms other than Alsa, but it should be resolved in Portaudio, one way or another.
Thanks for your assistance,
Alan
Hi Alan,
On 11.04.2012 19:00, Alan Horstmann wrote:
On Wednesday 11 April 2012 16:17, Daniel Mack wrote:
On 11.04.2012 12:59, Alan Horstmann wrote:
These are essentially issues in the way Portaudio interfaces; I am not suggesting driver bugs etc, but in summary:
a) The Audio 4DJ uses fixed _BE format, almost uniquely AFAICT from grepping driver source tree. Portaudio at present requests formats in the host platform endianness - so on a x86 PC an acceptable format is not available from the 'hw' device. Users seem reluctant to use 'plughw'.
Erm. Class compliant USB cards speak _LE formats only, and I'm not aware of any hardware that is able to switch endianess on a run-time configuration base.
Are you referring to USB cards? It looked to me like several PCI cards listed _BE and _LE variants of some formats in the driver?
Might be that there is hardware out there that lets the driver stack choose the audio format, but you can't rely on it. And from a hardware engineer's perspective, this is probably not easy to do in hardware, as the streaming code is likely implemented in programmable logic that is not that versatile.
From what I know, PortAudio is just a thin layer on top of ALSA and other sound APIs to ease the pain of cross-platform development of audio applications, right? What's wrong with letting ALSA convert the samples for you then?
That has been my perspective too, to use 'plughw' but some audio users believe the plug layer will necessarily give worse latency etc, and always want to get "as close as possible to the hardware".
Understood. But then you would at least need to take care for endianess format conversions and maybe even zero-padding in PortAudio.
Ok, I see your problem, but certainly, PortAudio is the place to get this fixed, not the driver.
Yes, but listing all subdevices does have it's own problems, as some cards have large numbers of them, for some reason.
The problem is probably which substreams to export to the user-API. But the PortAudio core should certainly be capable of handling subdevices.
So clearly, the issues you're seeing are due to missing features in PortAudio, and it should be fairly easy to add them there.
Well, I don't think it will be easy in fact, due to the constraints of a multi-platform API that is largely shaped by platforms other than Alsa, but it should be resolved in Portaudio, one way or another.
Thanks for your assistance,
No problem :) Let me know if I can help any further.
Daniel
At Wed, 11 Apr 2012 18:00:11 +0100, Alan Horstmann wrote:
From what I know, PortAudio is just a thin layer on top of ALSA and other sound APIs to ease the pain of cross-platform development of audio applications, right? What's wrong with letting ALSA convert the samples for you then?
That has been my perspective too, to use 'plughw' but some audio users believe the plug layer will necessarily give worse latency etc, and always want to get "as close as possible to the hardware".
The plughw doesn't influence on latnecy, at least, if it's only about the format conversion. If the rate conversion is included, it may have some influence because of the period size constraints.
Takashi
On Sun, 8 Apr 2012, Daniel Mack wrote:
Hi Alan,
On 06.04.2012 23:09, Alan Horstmann wrote:
At present I am involved with resolving some issues that have arisen from people using the Audio 4DJ interface with Portaudio, and I hoped it would be OK to check a few Alsa details with you? Unfortunately I have limited experience of USB audio.
What are those issues? Can you elaborate?
Apparently the 4 audio inputs/outputs appear as 2 stereo sub-devices on the first device, rather than a single 4-channel device - is this correct?
Yes.
Assuming that is correct, does that arise as a result of the intrinsic nature of the interface, or is it by developer choice in the driver (for example so that it can be opened as 2 stereo streams)? Is there (or could there be) a way to change this, eg by module option or udev rule? I notice in the source #define CHANNELS_PER_STREAM 2
The device itself implements 4 audio channels which are synced to each other. In other words: the hardware is not able to only enable one of them and leave the other ones paused or set sample rates individually.
When I implemented the driver, it seem most logical to follow the way the device denotes it channels though. The documentation and silk screen presents them as pairs of stereo, and so the driver does the same thing.
Is there a way at present that the device can be accessed as a single 4-channel stream other than by creating a custom ~asoundrc with a pcm definition using 'multi' to join the 2 stereo streams?
No, you would need to join them in software. But as all inputs and outputs share a single clock domain, there won't be any drift between them that need special attention.
I am interested in this too; what is the 'official' or proper definition of a subdevice in ALSA and where should they be used?
It feels like there are many different interpretations.
The Audio4DJ and other snd-usb-caiaq devices are easier for general use because of the sub-devices -- multiple stereo ins/outs, each on a subdevice.
Whereas snd-usb-audio presents all channels on one, which then have to be split using asoundrc files [1].
Different software prefers separate devices (eg. xwax) or a single wide one (eg. Mixxx)
Is it possible (or sensible) to have both co-exist? Perhaps one covering the whole interface, the other covering the default 'logical' layout.
Yet another example is Echo Layla3G, which presents 8 inputs on 8 subdevices which overlap:
hardware channels 0 1 2 3 4 5 6 7 ,0 x x x x x x x x ,1 x x x x x x x ,2 x x x x x x sub- ,3 x x x x x device ,4 x x x x ,5 x x x ,6 x x ,7 x
Opening .0 with 2 channels only disables .1. So you can open stereo pairs by opening 2 channels at each of:
hw:Layla3G,0,0 hw:Layla3G,0,2 hw:Layla3G,0,4 etc.
and mono channels by opening
hw:Layla3G,0,0 hw:Layla3G,0,1 hw:Layla3G,0,2 etc.
This is very useful, but feels more 'clever' rather than the use originally intended.
ALSA and asoundrc is flexible enough to deal with all these cases, but it can be rather confusing for users.
[1] http://www.pogo.org.uk/~mark/linuxdj/
participants (4)
-
Alan Horstmann -
Daniel Mack -
Mark Hills -
Takashi Iwai