Re: [alsa-devel] Zoom R16
Can't seem to compile 3.11 or 3.12 for the distro I am using (AVLInux)... tested it in Ubuntu Studio 13.10 and the quirk didn't seem to have any effect. The output of lsusb is the same, but the device doesn't show up as a sound card.
On Sun, Nov 24, 2013 at 9:18 AM, Daniel Mack daniel@zonque.org wrote:
I was able to compile 3.11.9 for AVLinux. The quirk does not work, dmesg returns this:
[ 40.759383] usb 2-8: New USB device found, idVendor=1686, idProduct=00dd [ 40.759387] usb 2-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 40.759390] usb 2-8: Product: R16 [ 40.759393] usb 2-8: Manufacturer: ZOOM Corporation [ 40.759396] usb 2-8: SerialNumber: 0 [ 40.760214] snd-usb-audio: probe of 2-8:1.0 failed with error -5 [ 45.760206] 6:1:1: cannot get freq at ep 0x3 [ 55.761231] 6:2:1: cannot get freq at ep 0x84
On Tue, Nov 26, 2013 at 1:22 PM, Jason Mancine jason@mancine.net wrote:
Actually, after a few more tries it DOES work for capture... but fails on playback just as it did with my original quirk.
Here are logs from a playback-only attempt. Looks like there are some packetsize errors and failing to set sample rate for playback
DMESG:
[ 319.651037] usb 2-8: new high-speed USB device number 10 using ehci-pci [ 319.959768] usb 2-8: config 1 interface 3 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 [ 319.959773] usb 2-8: config 1 interface 3 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64 [ 319.960512] usb 2-8: New USB device found, idVendor=1686, idProduct=00dd [ 319.960516] usb 2-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 319.960519] usb 2-8: Product: R16 [ 319.960522] usb 2-8: Manufacturer: ZOOM Corporation [ 319.960525] usb 2-8: SerialNumber: 0 [ 319.961397] snd-usb-audio: probe of 2-8:1.0 failed with error -5 [ 324.962217] 10:1:1: cannot get freq at ep 0x3 [ 334.963237] 10:2:1: cannot get freq at ep 0x84 [ 360.798326] 10:1:1: cannot get freq at ep 0x3 [ 365.803274] 10:1:1: cannot set freq 96000 to ep 0x3 [ 387.266266] 10:2:1: cannot get freq at ep 0x84 [ 392.272214] 10:2:1: cannot get freq at ep 0x84 [ 413.894325] 10:1:1: cannot get freq at ep 0x3 [ 418.899271] 10:1:1: cannot set freq 96000 to ep 0x3
JACK LOG:
loading driver ..
apparent rate = 96000
creating alsa driver ... -|hw:R16|1024|2|96000|8|0|nomon|swmeter|-|32bit
configuring for 96000Hz, period = 1024 frames (10.7 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
09:45:13.982 Server configuration saved to "/root/.jackdrc".
09:45:13.983 Statistics reset.
09:45:13.993 Client activated.
09:45:13.996 Buffer size change (0).
09:45:16.971 Buffer size change (1024).
09:45:16.972 JACK connection graph change.
09:45:16.997 JACK connection change.
09:45:28.900 Client deactivated.
09:45:28.903 JACK is stopping...
jack main caught signal 15
no message buffer overruns
09:45:33.936 JACK was stopped successfully.
09:45:38.539 JACK is starting...
09:45:38.539 /usr/bin/jackd -dalsa -dhw:R16 -r96000 -p1024 -n2 -P -o2
jackd 0.122.1
Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
09:45:38.570 JACK was started with PID=2919.
loading driver ..
apparent rate = 96000
creating alsa driver ... hw:R16|-|1024|2|96000|0|2|nomon|swmeter|-|32bit
configuring for 96000Hz, period = 1024 frames (10.7 ms), buffer = 2 periods
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 2 periods for playback
09:45:40.660 Server configuration saved to "/root/.jackdrc".
09:45:40.661 Statistics reset.
09:45:40.671 Client activated.
09:45:40.674 Buffer size change (0).
09:45:43.600 Buffer size change (1024).
09:45:43.601 JACK connection graph change.
09:45:43.675 JACK connection change.
ALSA: prepare error for playback on "hw:R16" (Connection timed out)
DRIVER NT: could not start driver
cannot start driver
no message buffer overruns
09:45:48.627 Shutdown notification.
09:45:48.628 Client deactivated.
09:45:48.631 JACK is being forced...
cannot read server event (Success)
cannot continue execution of the processing graph (Bad file descriptor)
graph error - calling shutdown handler
09:45:48.831 JACK was stopped successfully.
Thanks
On Thu, Nov 28, 2013 at 9:42 AM, Jason Mancine jason@mancine.net wrote:
It seems that ALSA is trying to initialize the device at 32-bit integer little endian despite having the .formats set to SNDRV_PCM_FMTBIT_S24_LE in the quirk. The device is 24-bit integer only. Other devices I have initialize properly at 24 bits.
Perhaps capture works because the device is running at 24 bits and sending info into the 32 bit driver... and playback fails because the driver is trying to force the device to operate at 32 bits, which it is incapable of???
Is there another/better way to force the bitrate to 24 bits?
At Fri, 6 Dec 2013 16:10:01 +0000 (UTC), Jason Mancine wrote:
Do you mean the 24bit physical size, i.e. each frame is packed in 3 bytes? If so, you used a wrong format. SNDRV_PCM_FMTBIT_S24_LE is for 24bit format packed in 32bit frame. If you need a 3-bytes frame, use SNDRV_PCM_FMTBIT_S24_3LE instead.
Takashi
With it set to 3LE format it fails on both capture and playback, and is still trying to initialize at 32 bits for both.
Any other formats I could try? On Dec 6, 2013 11:25 AM, "Takashi Iwai" tiwai@suse.de wrote:
I am still working on trying to get the R16 to work for playback. The problem is that no matter what .formats setting I use, ALSA sets the R16 to 32 bit LE (the R16 operates at 24 bit integer only). This is fine for capture as the R16 is sending a 24 bit stream into a 24-in-32 ALSA capture... but for playback, the 32 bit ALSA stream chokes when it hits the 24 bit integer R16 device.
So, the main question is how do I force ALSA to initialize this device at 24 bit integer?
For the record, here is the quirk that I am working with (working for capture, recognized for playback but crashes on data). Thanks for any suggestions.
{ /* ZOOM R16 in USB 2.0 mode */ USB_DEVICE(0x1686, 0x00dd), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { .ifnum = QUIRK_ANY_INTERFACE, .type = QUIRK_COMPOSITE, .data = (const struct snd_usb_audio_quirk[]) {
{ .ifnum = 0, .type = QUIRK_IGNORE_INTERFACE },
{ .ifnum = 1, /*PLAYBACK*/ .type = QUIRK_AUDIO_FIXED_ENDPOINT, .data = & (const struct audioformat) { .formats = SNDRV_PCM_FMTBIT_S24_LE, .channels = 2, .iface = 0, .altsetting = 1, altset_idx = 1, .attributes = UAC_EP_CS_ATTR_SAMPLE_RATE, .endpoint = 0x03, .ep_attr = 9, .rates = SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 | SNDRV_PCM_RATE_88200 | SNDRV_PCM_RATE_96000, .rate_min = 44100, .rate_max = 96000, .nr_rates = 4, .rate_table = (unsigned int[]) { 44100, 48000, 88200, 96000 } } },
{ .ifnum = 2, /*CAPTURE*/ .type = QUIRK_AUDIO_FIXED_ENDPOINT, .data = & (const struct audioformat) { .formats = SNDRV_PCM_FMTBIT_S24_LE, .channels = 8, .iface = 0, .altsetting = 1, .altset_idx = 1, .attributes = UAC_EP_CS_ATTR_SAMPLE_RATE, .endpoint = 0x84, .ep_attr = 13, .rates = SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 | SNDRV_PCM_RATE_88200 | SNDRV_PCM_RATE_96000, .rate_min = 44100, .rate_max = 96000, .nr_rates = 4, .rate_table = (unsigned int[]) { 44100, 48000, 88200, 96000 } } },
{ .ifnum = 3, .type = QUIRK_MIDI_STANDARD_INTERFACE },
{ .ifnum = .1 },
}
}
},
On Fri, Dec 6, 2013 at 12:28 PM, Jason Mancine jason@mancine.net wrote:
On Monday 10 March 2014 14:36, Jason Mancine wrote:
I am still working on trying to get the R16 to work for playback.
So, the main question is how do I force ALSA to initialize this device at 24 bit integer?
Isn't the answer in Takashi's original reply...?
Many USB devices have this...
.formats = SNDRV_PCM_FMTBIT_S24_3LE,
instead. That would apply for capture also. Or is that what you have been trying?
Regards
Alan
Yes, I have tried those .formats with no luck...it still initializes at 32 On Mar 10, 2014 4:29 PM, "Alan Horstmann" gineera@aspect135.co.uk wrote:
recompiled the kernel for each format On Mar 11, 2014 3:09 AM, "Takashi Iwai" tiwai@suse.de wrote:
Sorry, i am unsure how to not top post when replying via email.
With capture and playback .formats set to SNDRV_PCM_FMTBIT_S24_3LE, jack log shows:
ALSA: final selected sample format for playback: 32bit integer little-endian
and
/proc/asound/R16/stream0 shows:
Playback: Status: Stop Interface 1 Altset 1 Format: S32_LE Channels: 2 Endpoint: 3 OUT (ADAPTIVE) Rates: 44100, 48000, 88200, 96000 Data packet interval: 125 us
Capture: Status: Stop Interface 2 Altset 1 Format: S32_LE Channels: 8 Endpoint: 4 IN (SYNC) Rates: 44100, 48000, 88200, 96000 Data packet interval: 125 us
initializes at
playback.
wrote:
>> Do you mean the 24bit physical size, i.e. each frame is
packed in
3
>> bytes? If so, you used a wrong format.
SNDRV_PCM_FMTBIT_S24_LE
is
>> for 24bit format packed in 32bit frame. If you need a
3-bytes
QUIRK_AUDIO_FIXED_ENDPOINT,
.data = & (const struct
audioformat)
SNDRV_PCM_FMTBIT_S24_LE,
.formats =
SNDRV_PCM_FMTBIT_S24_3LE,
instead. That would apply for capture also. Or is that what you
have
On Mar 11, 2014 9:40 AM, "Takashi Iwai" tiwai@suse.de wrote:
Just verified only 96000 shows as available when I omit the other rates from the quirk.
FWIW, other users at linux audio forum are seeing the same result of ending up with S32_LE regardless of .formats setting.
But with capture working, wondering if it is possible that the S32_LE is indeed the correct format, and the playback problem is something else... one user is investigating possible wrong UAC version. There are get/set sample rate errors on playback as well.
Thanks for your help, any ideas are appreciated!
jason
gineera@aspect135.co.uk>
this
you
At Tue, 11 Mar 2014 11:16:04 -0400, Jason Mancine wrote:
Then try to add more format bits there and see whether the proc file shows them, too. If the proc file doesn't show, debug why it doesn't do so. The proc output (in proc__dump_substream_formats()) is basically a collection of audioformat list, which is added directly by create_fixed_stream_quirk().
At this moment, it doesn't matter what jack shows. The only thing to be checked is whether the driver takes the value as is or not.
FWIW, other users at linux audio forum are seeing the same result of ending up with S32_LE regardless of .formats setting.
Do you mean in proc or jack output?
But with capture working, wondering if it is possible that the S32_LE is indeed the correct format, and the playback problem is something else...
Possibly. But you must figure out what you're debugging at first.
Takashi
participants (3)
-
Alan Horstmann -
Jason Mancine -
Takashi Iwai