Re: [alsa-devel] usb-audio: Reloop Play support (TI TUSB3200AC)
[Please do not drop the mailing list address]
On 19.10.2012 15:45, Didier 'Ptitjes' Villevalois wrote:
On ven., 2012-10-19 at 15:20 +0200, Daniel Mack wrote:
On 19.10.2012 15:09, Didier 'Ptitjes' Villevalois wrote:
Hello,
I've bought a Reloop Play usb soundcard and I'd like to make it work with ALSA.
It is a 4-channels USB soundcard. It is currently correctly recognized by ALSA as a 4-channels soundcard and I can correctly open the channels and feed them with audio. However, no audio is output by the box.
You're most probably affected by a regression in the driver that was fixes in 3.6.0 and 3.5.5 (and all later kernels). Could you please try one of these and tell us if that works?
Sure, I'll do that now (I'm currently using 3.5.4 + mbp8,3 patches). I guess 3.5.7 is OK ? I'm building it now and will reboot on that.
Any kernel >= 3.6.0 and 3.5.5 should be ok.
It seems to contain a Texas Instrument TUSB3200AC chipset (same chipset as the Maya44 USB and Hercules DJ console). I guess the problem is a firmware problem but I don't know what to do about it.
I've got a MacOS X driver that works correctly, if that of any help. (I suppose the Windows driver works too but I don't have any Windows at hand.)
Did you install any vendor driver on OS X or does it just work with the one that ships with the OS?
Yep, I had to install the Vendor-provided driver.
What was the effect without that special driver? Could you see the device listed in the AudioMIDISetup? Could you stream audio? IOW, is the effect you see there comparable to how your Linux box behaves? You could try and remove that driver again and see what happens.
But it seems the built-in USB soundcard support on MacOS is very poor.
No it's not. In fact, it's actually very good. Vendors who keep their hardware compliant to the USB audio spec don't have to ship any driver at all. And this is how it should be on Linux, too.
Also the mpkg install file (inside the provided install dmg file) was called something like "firmware0_and_driver.mpkg". This is why I suspected a firmware problem. However I tried to look at the package content and did not find any .bin file or whatever could be a standalone firmware file. Maybe it is embedded in the driver install executable.
Maybe, but they could also write the firmware permanently to the device once with that tool. That would be perfect for Linux users.
Daniel
On ven., 2012-10-19 at 15:53 +0200, Daniel Mack wrote:
[Please do not drop the mailing list address]
Oups my bad... Sorry!
On 19.10.2012 15:45, Didier 'Ptitjes' Villevalois wrote:
On ven., 2012-10-19 at 15:20 +0200, Daniel Mack wrote:
On 19.10.2012 15:09, Didier 'Ptitjes' Villevalois wrote:
Hello,
I've bought a Reloop Play usb soundcard and I'd like to make it work with ALSA.
It is a 4-channels USB soundcard. It is currently correctly recognized by ALSA as a 4-channels soundcard and I can correctly open the channels and feed them with audio. However, no audio is output by the box.
You're most probably affected by a regression in the driver that was fixes in 3.6.0 and 3.5.5 (and all later kernels). Could you please try one of these and tell us if that works?
Sure, I'll do that now (I'm currently using 3.5.4 + mbp8,3 patches). I guess 3.5.7 is OK ? I'm building it now and will reboot on that.
Any kernel >= 3.6.0 and 3.5.5 should be ok.
So there was no change after rebooting with 3.5.7 kernel.
It seems to contain a Texas Instrument TUSB3200AC chipset (same chipset as the Maya44 USB and Hercules DJ console). I guess the problem is a firmware problem but I don't know what to do about it.
I've got a MacOS X driver that works correctly, if that of any help. (I suppose the Windows driver works too but I don't have any Windows at hand.)
Did you install any vendor driver on OS X or does it just work with the one that ships with the OS?
Yep, I had to install the Vendor-provided driver.
What was the effect without that special driver? Could you see the device listed in the AudioMIDISetup? Could you stream audio? IOW, is the effect you see there comparable to how your Linux box behaves? You could try and remove that driver again and see what happens.
So here is what I did:
1) Removed the MacOs X driver and rebooted 2) Launched AudioMIDISetup (I did not know of this tool before :p) 3) Launched Mixxx
Now the box is outputing some crazy sound when Mixxx is not playing. When I start playing a track some more noise adds to the existing noise. Is this simply a PCM format error (sample rate/bit depth) ??
The fun thing (if I can say that) is that after rebooting to Linux 3.5.7 there is now the same sound when I run Mixxx/Linux!! And I can observe the same added noise when I launch a track.
But it seems the built-in USB soundcard support on MacOS is very poor.
No it's not. In fact, it's actually very good. Vendors who keep their hardware compliant to the USB audio spec don't have to ship any driver at all. And this is how it should be on Linux, too.
Ah ok!
Also the mpkg install file (inside the provided install dmg file) was called something like "firmware0_and_driver.mpkg". This is why I suspected a firmware problem. However I tried to look at the package content and did not find any .bin file or whatever could be a standalone firmware file. Maybe it is embedded in the driver install executable.
Maybe, but they could also write the firmware permanently to the device once with that tool. That would be perfect for Linux users.
I took some screenshots of the AudioMIDISetup app and of the content of the driver install packages. I don't if that can be of any help. You can see them here: http://ptitjes.free.fr/screenshots/
I don't know what step I should take know. Reinstalling drivers on OS X to see if there is any change ?
Thanks again for your help. Didier.
On 19.10.2012 17:09, Didier 'Ptitjes' Villevalois wrote:
On ven., 2012-10-19 at 15:53 +0200, Daniel Mack wrote:
It seems to contain a Texas Instrument TUSB3200AC chipset (same chipset as the Maya44 USB and Hercules DJ console). I guess the problem is a firmware problem but I don't know what to do about it.
I've got a MacOS X driver that works correctly, if that of any help. (I suppose the Windows driver works too but I don't have any Windows at hand.)
Did you install any vendor driver on OS X or does it just work with the one that ships with the OS?
Yep, I had to install the Vendor-provided driver.
What was the effect without that special driver? Could you see the device listed in the AudioMIDISetup? Could you stream audio? IOW, is the effect you see there comparable to how your Linux box behaves? You could try and remove that driver again and see what happens.
So here is what I did:
- Removed the MacOs X driver and rebooted
- Launched AudioMIDISetup (I did not know of this tool before :p)
- Launched Mixxx
Now the box is outputing some crazy sound when Mixxx is not playing. When I start playing a track some more noise adds to the existing noise. Is this simply a PCM format error (sample rate/bit depth) ??
The fun thing (if I can say that) is that after rebooting to Linux 3.5.7 there is now the same sound when I run Mixxx/Linux!! And I can observe the same added noise when I launch a track.
Ok, so this proves that their driver downloads a volatile firmware to the device, which is rather bad news.
What you observe also tells us that even the new firmware is not compliant to the USB audio standard which is really strange. I don't know what they wouldn't go the class-compliant way with their firmware as that's much easier than writing an own driver :-/
Also the mpkg install file (inside the provided install dmg file) was called something like "firmware0_and_driver.mpkg". This is why I suspected a firmware problem. However I tried to look at the package content and did not find any .bin file or whatever could be a standalone firmware file. Maybe it is embedded in the driver install executable.
Maybe, but they could also write the firmware permanently to the device once with that tool. That would be perfect for Linux users.
I took some screenshots of the AudioMIDISetup app and of the content of the driver install packages. I don't if that can be of any help. You can see them here: http://ptitjes.free.fr/screenshots/
I don't know what step I should take know. Reinstalling drivers on OS X to see if there is any change ?
Ok, if you want to work on this, here are some ideas.
The first thing is that you need to understand how the driver and the device communicate. It's probably some protocol that resembles to the UAC standard in either version 1 or 2, but there has to be some difference, otherwise the device would already be working.
You can do that by sniffing the packets on the wire, either with an USB hardware analyzer or by some software tracer tool. Once you got a dump of the setup phase and some seconds of streaming, you have to analyze and reverse-egineer it.
As soon as you know where the differences are between the UAC standard protocol that the generic Linux driver implements and the one your device speaks is, you should share this information here so we can discuss what would be a good way to teach the driver that protocol. In some cases, the problem can be solved by simply adding a quirks entry and override the descriptor set with some hard-coded values (quirks-table.h). In other cases, the protocol code has to be tweaked by adding special cases.
Unfortunately, in the case of your device, you would also need to extract the firmware from the bitstream and add some functions to the driver to do the download. Which is really sad and will be quite some work to do.
Let me know of you make any progress here.
Daniel
On ven., 2012-10-19 at 20:02 +0200, Daniel Mack wrote: [...]
Let me know of you make any progress here.
I diff-ed the ioreg output when the play is connected without the driver (-) and with the driver (+). So I can see that it is using its proprietary driver.
http://ptitjes.free.fr/reloop-play/play-ioreg-without-and-with-driver.diff
I also traced (with Apple's USB Probe tool) the USB when connecting the PLAY.
At log level 6: http://ptitjes.free.fr/reloop-play/usb-log-withdriver-l6.txt
At log level 7: (3.5Mo!!) http://ptitjes.free.fr/reloop-play/usb-log-withdriver-l7.txt
I have to do the same thing when streaming some sound. But should I output some easily recognizable sound ? Something like a sine or some silence ?
Didier.
On 20.10.2012 12:22, Didier 'Ptitjes' Villevalois wrote:
On ven., 2012-10-19 at 20:02 +0200, Daniel Mack wrote: [...]
Let me know of you make any progress here.
I diff-ed the ioreg output when the play is connected without the driver (-) and with the driver (+). So I can see that it is using its proprietary driver.
http://ptitjes.free.fr/reloop-play/play-ioreg-without-and-with-driver.diff
Hmm, that output doesn't make a whole lot of sense. Could you do the same thing with lsusb under Linux? Boot into Linux after the OS X driver downloaded the firmware for one run, and freshly connect (power cycle) device for the other.
I also traced (with Apple's USB Probe tool) the USB when connecting the PLAY.
At log level 6: http://ptitjes.free.fr/reloop-play/usb-log-withdriver-l6.txt
At log level 7: (3.5Mo!!) http://ptitjes.free.fr/reloop-play/usb-log-withdriver-l7.txt
I have to do the same thing when streaming some sound. But should I output some easily recognizable sound ? Something like a sine or some silence ?
Yes, that can help. You could for example stream a sine that is on just one channel, so you can debug the muxing (interleaving) on the wire. Or a sine at ~ -48dB, which would just leave the 8 MSB empty (to check the endianess).
Most probably though, the streaming mode is already supported by the Linux driver, and it's the recognition of the right format that fails, or the cards needs a different setup sequence than the generic one.
Daniel
I'm making some progress!! :)
I did not yet tried what you suggested below. But I did add that to quirk-table.h:
#if 1 /* Reloop Play */ { USB_DEVICE(0x200c, 0x100b), .bInterfaceClass = USB_CLASS_PER_INTERFACE, .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) { .vendor_name = "Reloop", .product_name = "Play", .ifnum = QUIRK_ANY_INTERFACE, .type = QUIRK_COMPOSITE, .data = &(const struct snd_usb_audio_quirk[]) { { .ifnum = 0, .type = QUIRK_IGNORE_INTERFACE, }, { .ifnum = 1, .type = QUIRK_AUDIO_FIXED_ENDPOINT, .data = &(const struct audioformat) { .formats = SNDRV_PCM_FMTBIT_S24_LE, .channels = 4, .iface = 1, .altsetting = 1, .altset_idx = 1, .attributes = 0, .endpoint = 0x01, .ep_attr = 0x05, .rates = SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000, .rate_min = 44100, .rate_max = 48000, .nr_rates = 2, .rate_table = (unsigned int[]) { 44100, 48000 } } }, { .ifnum = -1 } } } }, #endif
Did some: rmmod snd-usb-audio && make modules && cp -v sound/usb/snd-usb*.ko /lib/modules/3.5.7-mbp83+/kernel/sound/usb/
Added this to my .asoundrc:
pcm.play { type plug slave { pcm "hw:1" format S24_LE channels 4 } }
And now I don't have strange sounds when plugin the card but silence. And I can hear a distant "Front Center" above some noise (but no noise in-beetween the words) when doing :
didier@didier-laptop ~ $ cat /proc/asound/card1/stream0 && aplay -Dplay /usr/share/sounds/alsa/Front_Center.wav Reloop Play at usb-0000:00:1a.7-1.3, full speed : USB Audio
Playback: Status: Stop Interface 1 Altset 1 Format: S24_LE Channels: 4 Endpoint: 1 OUT (ADAPTIVE) Rates: 44100, 48000 Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
I guess now is just finding the correct values for:
- .formats (which can any of the 24 bits formats) - .maxPacketSize (not clear to me what this is) - .ep_attr (not clear to me what a endpoint is and what are those ASYNC, ADAPTIVE, ISOCHRONOUS attributes are nor the hex value table)
Am I right ??
Didier.
On sam., 2012-10-20 at 14:49 +0200, Daniel Mack wrote:
On 20.10.2012 12:22, Didier 'Ptitjes' Villevalois wrote:
On ven., 2012-10-19 at 20:02 +0200, Daniel Mack wrote: [...]
Let me know of you make any progress here.
I diff-ed the ioreg output when the play is connected without the driver (-) and with the driver (+). So I can see that it is using its proprietary driver.
http://ptitjes.free.fr/reloop-play/play-ioreg-without-and-with-driver.diff
Hmm, that output doesn't make a whole lot of sense. Could you do the same thing with lsusb under Linux? Boot into Linux after the OS X driver downloaded the firmware for one run, and freshly connect (power cycle) device for the other.
I also traced (with Apple's USB Probe tool) the USB when connecting the PLAY.
At log level 6: http://ptitjes.free.fr/reloop-play/usb-log-withdriver-l6.txt
At log level 7: (3.5Mo!!) http://ptitjes.free.fr/reloop-play/usb-log-withdriver-l7.txt
I have to do the same thing when streaming some sound. But should I output some easily recognizable sound ? Something like a sine or some silence ?
Yes, that can help. You could for example stream a sine that is on just one channel, so you can debug the muxing (interleaving) on the wire. Or a sine at ~ -48dB, which would just leave the 8 MSB empty (to check the endianess).
Most probably though, the streaming mode is already supported by the Linux driver, and it's the recognition of the right format that fails, or the cards needs a different setup sequence than the generic one.
Daniel
On 20.10.2012 15:03, Didier 'Ptitjes' Villevalois wrote:
I'm making some progress!! :)
Very good.
I did not yet tried what you suggested below. But I did add that to quirk-table.h:
#if 1 /* Reloop Play */ { USB_DEVICE(0x200c, 0x100b), .bInterfaceClass = USB_CLASS_PER_INTERFACE, .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) { .vendor_name = "Reloop", .product_name = "Play", .ifnum = QUIRK_ANY_INTERFACE, .type = QUIRK_COMPOSITE, .data = &(const struct snd_usb_audio_quirk[]) { { .ifnum = 0, .type = QUIRK_IGNORE_INTERFACE, }, { .ifnum = 1, .type = QUIRK_AUDIO_FIXED_ENDPOINT, .data = &(const struct audioformat) { .formats = SNDRV_PCM_FMTBIT_S24_LE, .channels = 4, .iface = 1, .altsetting = 1, .altset_idx = 1, .attributes = 0, .endpoint = 0x01, .ep_attr = 0x05, .rates = SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000, .rate_min = 44100, .rate_max = 48000, .nr_rates = 2, .rate_table = (unsigned int[]) { 44100, 48000 } } }, { .ifnum = -1 } } } }, #endif
Did some: rmmod snd-usb-audio && make modules && cp -v sound/usb/snd-usb*.ko /lib/modules/3.5.7-mbp83+/kernel/sound/usb/
Added this to my .asoundrc:
pcm.play { type plug slave { pcm "hw:1" format S24_LE channels 4 } }
And now I don't have strange sounds when plugin the card but silence. And I can hear a distant "Front Center" above some noise (but no noise in-beetween the words) when doing :
Ok, but you still need the firmware I guess? Or does this even work after you plugged in the device under Linux?
didier@didier-laptop ~ $ cat /proc/asound/card1/stream0 && aplay -Dplay /usr/share/sounds/alsa/Front_Center.wav Reloop Play at usb-0000:00:1a.7-1.3, full speed : USB Audio
Playback: Status: Stop Interface 1 Altset 1 Format: S24_LE Channels: 4 Endpoint: 1 OUT (ADAPTIVE) Rates: 44100, 48000 Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
I guess now is just finding the correct values for:
- .formats (which can any of the 24 bits formats)
- .maxPacketSize (not clear to me what this is)
- .ep_attr (not clear to me what a endpoint is and what are those ASYNC,
ADAPTIVE, ISOCHRONOUS attributes are nor the hex value table)
Am I right ??
Possibly yes. You can try and blindly guess them, or really dive into the logs and try to understand the reason.
Daniel
[I hope I'm not making too much noise on the ML...]
On sam., 2012-10-20 at 15:06 +0200, Daniel Mack wrote:
And now I don't have strange sounds when plugin the card but silence. And I can hear a distant "Front Center" above some noise (but no noise in-beetween the words) when doing :
Ok, but you still need the firmware I guess? Or does this even work after you plugged in the device under Linux?
I can unplug, rmmod, replug and that behaviour remains. I understand that this means their firmware is not volatile, right ?
i experienced the same errors with my reloop play. i once had it functioning but now i only get some weird noises
Daniel,
I noticed something strange on the screenshots. AudioMIDISetup says the Reloop Play is a 24bit device (and indeed this is what is advertised on the Reloop page http://www.reloop.com/reloop-play). However, when I inspect the proposed audio formats through Javasound the only format proposed are:
Format: PCM_SIGNED unknown sample rate, 16 bit, mono, 2 bytes/frame, little-endian Format: PCM_SIGNED unknown sample rate, 16 bit, mono, 2 bytes/frame, big-endian Format: PCM_SIGNED unknown sample rate, 16 bit, stereo, 4 bytes/frame, little-endian Format: PCM_SIGNED unknown sample rate, 16 bit, stereo, 4 bytes/frame, big-endian Format: PCM_SIGNED unknown sample rate, 16 bit, 3 channels, 6 bytes/frame, little-endian Format: PCM_SIGNED unknown sample rate, 16 bit, 3 channels, 6 bytes/frame, big-endian Format: PCM_SIGNED unknown sample rate, 16 bit, 4 channels, 8 bytes/frame, little-endian Format: PCM_SIGNED unknown sample rate, 16 bit, 4 channels, 8 bytes/frame, big-endian Format: PCM_SIGNED unknown sample rate, 8 bit, mono, 1 bytes/frame, Format: PCM_UNSIGNED unknown sample rate, 8 bit, mono, 1 bytes/frame, Format: PCM_SIGNED unknown sample rate, 8 bit, stereo, 2 bytes/frame, Format: PCM_UNSIGNED unknown sample rate, 8 bit, stereo, 2 bytes/frame, Format: PCM_SIGNED unknown sample rate, 8 bit, 3 channels, 3 bytes/frame, Format: PCM_UNSIGNED unknown sample rate, 8 bit, 3 channels, 3 bytes/frame, Format: PCM_SIGNED unknown sample rate, 8 bit, 4 channels, 4 bytes/frame, Format: PCM_UNSIGNED unknown sample rate, 8 bit, 4 channels, 4 bytes/frame,
Is it possible that ALSA does not correctly see that it is a 24-bit soundcard ?
Didier.
On 19.10.2012 17:28, Didier 'Ptitjes' Villevalois wrote:
Daniel,
I noticed something strange on the screenshots. AudioMIDISetup says the Reloop Play is a 24bit device (and indeed this is what is advertised on the Reloop page http://www.reloop.com/reloop-play). However, when I inspect the proposed audio formats through Javasound the only format proposed are:
[...]
Is it possible that ALSA does not correctly see that it is a 24-bit soundcard ?
Yes, but I doubt that the only reason for them to ship an own driver.
Could you post the output of "lsusb -v" please? For both cases: the device freshly plugged in under Linux, and after the OSX driver downloaded its firmware. You can already check whether you spot any differences between them ...
Daniel
participants (3)
-
Ansgar Scheffold -
Daniel Mack -
Didier 'Ptitjes' Villevalois