[alsa-devel] USB audio device startup question

[Felipe Tonello]

Hi Ricard,

On Sun, Oct 4, 2015 at 5:45 AM, Ricard Wanderlof
<ricard.wanderlof at axis.com> wrote:
>
> (This is in reference to getting the Zoom R16 to work, but the main query
> in this post is of a more general nature).
>
> In trying to get a Zoom R16 in audio interface mode to work in Linux I'm
> trying to understand how the USB-audio (snd-usb-audio module) subsystem
> works in Linux. I've looked in the USB audio version 1 and 2 documents, as
> well as the USB 2.0 standard, but there are some things that don't seem to
> be well defined there, like exactly how the audio data is packaged in the
> isochronous transfer packets.
>
> I've been using Wireshark to visualize the USB communication, and also
> comparing with the corresponding transfers on a Windows box by dumping the
> traffic with USBPcap.
>
> The only other USB audio interface I have access to here is an Edirol
> UA-5. I've noted that when plugging in the UA-5, there's period of about
> 15 seconds during which capture and playback are set up and audio data
> transferred, after which the interface is shut down again. When enabling
> the R16, during the corresponding initial period I see playback data but
> no capture data during this phase. I don't know if that is significant or
> not, for instance, if the lack of capture data during this phase is
> because the playback is not working as it should.
>
> My question is: what governs this startup phase, can someone point to a
> specific part of the code or some documentation describing what is
> supposed to go on here? Is it some sort of device test period to determine
> that the device actually works?

sound/usb/quirks-table.h and sound/usb/quirks.c

The probe functions basically calls snd_usb_create_quirk() on each of
the snd_usb_audio_quirk.data item of the array. Make sure that the
quirk structure is correct for the ZOOM R16.

>
> The problem with the R16 is that although capture works fine, playback
> doesn't result in any audio. With the correct quirk set up (most
> importantly, using a 24 bit format), aplay appears to work fine with no
> errors, neither are there any complaints from dmesg, and looking at the
> communication I can see outgoing isochronous data from the host being
> transferred fine.
>
> More work needs to be done, but I've looked at the startup of the Windows
> driver which is deceptively simple: it basically just sets the
> appropriate capture and playback interfaces, together with sending off
> some sample rate USB control commands, the isochronous link comes up and
> that seems to be it. I've tried to emulate the specific USB control
> commands in Linux, as well as add some delays that there appear to be in
> the Windows driver, but so far it hasn't made a difference.

Can you copy your dmesg output here? Check the /proc/asound/cards and
see if your card is there. If it is, check the
/proc/asound/cardN/XX/info if it is correct.

Felipe