USB audio devices on Audio 4DJ and similar

USB audio devices on Audio 4DJ and similar

[Alan Horstmann]

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

Re: USB audio devices on Audio 4DJ and similar

[Daniel Mack]

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

Re: USB audio devices on Audio 4DJ and similar

[Alan Horstmann]

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

Re: USB audio devices on Audio 4DJ and similar

[Daniel Mack]

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

Re: USB audio devices on Audio 4DJ and similar

[Daniel Mack]

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?"

Re: USB audio devices on Audio 4DJ and similar

[Alan Horstmann]

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

Re: USB audio devices on Audio 4DJ and similar

[Daniel Mack]

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

Re: USB audio devices on Audio 4DJ and similar

[Takashi Iwai]

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

When to use sub-devices? (was Re: USB audio devices on Audio 4DJ and similar)

[Mark Hills]

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/

-- 
Mark