Re: [alsa-devel] RE : M-Audio Audiophile USB, native little endian (S16_LE) ?
I don't know if this is already known (?), but the M-Audio Audiophile USB seem to be possible to run in native S16_LE mode if initialized with device_setup=0x01 (possibly with 0x11 also, have not tested that).
No I wasn't aware of this ! How did you figure this out ?
When initialized with device_setup=0x01 my box only produces noise. With 0x00 (or omitted) it works ok, except for spdif out sometimes not being setup correctly (no signal detect by the amp it is connected to). 0x09 seem to work without problems. Have not tested any other combinations.
Using a setup with 0x01 and preparing a raw S16_LE file (with "mpg123 -s") and then playing with "aplay -D hw:2 -f S16_BE -r 44100 -c 2" produced good quality sound. This made me suspect that the device really is operating in native S16_LE.
When you say 'it is possible' to run it in S16_LE do you mean it both recognizes S16_BE and S16_LE or only S16_LE ?
Sorry, a bit unclear. Only S16_LE.
Mine works with S16_BE but I must admit I haven't tested with S16_LE.
Ok, this then seem to be something that has changed over time in the firmware (or hw) ? The fw version of my box is 1.01.
Regards.
/Håkan
I don't know if this is already known (?), but the M-Audio Audiophile USB seem to be possible to run in native S16_LE mode if initialized with device_setup=0x01 (possibly with 0x11 also, have not tested that).
Hakan,
Seems that you're right. After some more tests, I was able to play a raw file supposed to be S16_BE (recorded from my audiophile usb) to a Little endian only device.
I think we should fix this then, however I think that we should prefer a fix that do not use device_setup too much because it is something that could disapear in the future (see the old thread "[PATCH 1/2] M-Audio USB").
You'll find attached an equivalent fix that checks alt-settings instead of device_setup param: Can you try it Hakan ?
Moreover, it adds an extra reset-to-altset0 call at module initialization time which proves to be useful to switch sample depth modes without having to turn off the device. It is taken from Pavel Polischouk's patch which wasn't really finalized (at least until now). (Pavel are you still reading to this list?)
Takashi, let me know if you want to apply one of the proposed fixes, cause I'll have to update the Documentation as well.
Regards, Thibault
At Tue, 10 Jul 2007 23:22:03 +0200, Thibault Le Meur wrote:
Takashi, let me know if you want to apply one of the proposed fixes, cause I'll have to update the Documentation as well.
Your patch looks fine to me. If it works for you all, I'm willing to apply it.
Takashi
At Tue, 10 Jul 2007 23:22:03 +0200, Thibault Le Meur wrote:
Takashi, let me know if you want to apply one of the proposed fixes, cause I'll have to update the Documentation as well.
Your patch looks fine to me. If it works for you all, I'm willing to apply it.
Takashi
Ok, since Hakan reported a success for this patch, I'll prepare a new diff including Documentation update.
Thibault
Ok, since Hakan reported a success for this patch, I'll prepare a new diff including Documentation update.
Takashi,
What is the deadline and what will be the alsa-release/kernel-version including this patch (info needed for doc update) ?
Regards, Thibault
At Wed, 11 Jul 2007 12:44:27 +0200, Thibault Le Meur wrote:
Ok, since Hakan reported a success for this patch, I'll prepare a new diff including Documentation update.
Takashi,
What is the deadline and what will be the alsa-release/kernel-version including this patch (info needed for doc update) ?
We need it ASAP because of the merge window for 2.6.23 kernel. The patch should be prepared against the latest HG tree. I guess the patch to 1.0.14 should be applicable to the current version without hitches, though.
Takashi
-----Message d'origine----- De : Takashi Iwai [mailto:tiwai@suse.de] Envoyé : mercredi 11 juillet 2007 12:47 À : Thibault Le Meur Cc : alsa-devel@alsa-project.org; 'Hakan Lennestal' Objet : Re: RE : [alsa-devel] RE : RE : M-Audio Audiophile USB,native little endian (S16_LE) ?
At Wed, 11 Jul 2007 12:44:27 +0200, Thibault Le Meur wrote:
Ok, since Hakan reported a success for this patch, I'll prepare a new diff including Documentation update.
Takashi,
What is the deadline and what will be the
alsa-release/kernel-version
including this patch (info needed for doc update) ?
We need it ASAP because of the merge window for 2.6.23 kernel.
I'll work on this tonight then.
The patch should be prepared against the latest HG tree. I guess the patch to 1.0.14 should be applicable to the current version without hitches, though.
I'll generate it against hg-tree as was my last patch.
Thanks, Thibault.
Ok, since Hakan reported a success for this patch, I'll prepare a new diff including Documentation update.
Here is a slightly modified fix which takes into account a special case: when no device_setup is used, all interfaces are Big-endians even if used in 16bits modes. So I had to add a check for device_setup beeing 0x00 or not.
Summary: Audiophile-usb fix (corrects little-endianness in 16bit modes, resets interfaces at device initialization, and updates the documentation)
Signed-Of-By: Thibault Le Meur Thibault.LeMeur@supelec.fr
At Wed, 11 Jul 2007 23:48:03 +0200, Thibault Le Meur wrote:
Ok, since Hakan reported a success for this patch, I'll prepare a new diff including Documentation update.
Here is a slightly modified fix which takes into account a special case: when no device_setup is used, all interfaces are Big-endians even if used in 16bits modes. So I had to add a check for device_setup beeing 0x00 or not.
Summary: Audiophile-usb fix (corrects little-endianness in 16bit modes, resets interfaces at device initialization, and updates the documentation)
Signed-Of-By: Thibault Le Meur Thibault.LeMeur@supelec.fr
Thanks, applied now.
Takashi
-
Summary: Audiophile-usb fix (corrects little-endianness in 16bit modes, resets interfaces at device initialization, and updates the documentation)
Signed-Of-By: Thibault Le Meur Thibault.LeMeur@supelec.fr
Thanks, applied now.
Takashi
Hi,
Hakan reported to me (off-list) that the AC3 function works correctly with the device except in device_setup=0x00 mode because the interface is reported to be little endian whereas it is in fact big-endian (in this mode only).
With the help of Hakan I made a fix and updated the doc accordingly. Hakan could you test this fix (to be applied after my last one) and report if it is ok for you ?
Takashi, in case everything is ok and you want to apply the patch:
Summary: Fixed AC3 interface in device_setup=0x00 mode thanks to Hakan Lennestal and updated documentation Signed-Of-By: Thibault Le Meur Thibault.LeMeur@supelec.fr
Thanks in advance, Thibault
At Thu, 12 Jul 2007 23:21:19 +0200, Thibault Le Meur wrote:
Summary: Audiophile-usb fix (corrects little-endianness in 16bit modes, resets interfaces at device initialization, and updates the documentation)
Signed-Of-By: Thibault Le Meur Thibault.LeMeur@supelec.fr
Thanks, applied now.
Takashi
Hi,
Hakan reported to me (off-list) that the AC3 function works correctly with the device except in device_setup=0x00 mode because the interface is reported to be little endian whereas it is in fact big-endian (in this mode only).
With the help of Hakan I made a fix and updated the doc accordingly. Hakan could you test this fix (to be applied after my last one) and report if it is ok for you ?
Takashi, in case everything is ok and you want to apply the patch:
Summary: Fixed AC3 interface in device_setup=0x00 mode thanks to Hakan Lennestal and updated documentation Signed-Of-By: Thibault Le Meur Thibault.LeMeur@supelec.fr
Thanks, now applied to HG tree.
Takashi
Hi,
For the M-Audio Audiophile USB device I still see 3 tasks that could be done to improve support under Alsa:
1- Remap the Alsa 'hardware pcm devices'
Currently: * hw:1,0 is bound to the Analog interface in playback mode but to the Digital interface in capture mode * hw:1,1 is bound to the Analog interface in capture mode but to the Digital interface in playback mode
It would be great if the one pcm device+subdevice was always linked to the same interface (Analog or Digital) Can anyone could point me to the piece of code that chooses the mapping between the device physiscal interface and Alsa's pcm interface? I'll try to see if I can fix this.
2- Have the device able to act as a 4 channels-in + 4 channels-out combined device under Jackd I had no success in defining a multi pcm device and have it work under Jackd (but this might be a Jackd issue).
Just a question about this: in the "Multiple ICE1712 Sound Cards" tutorial, it is said that : "A change was made in alsa-lib-1.0.9rc1 which had the unintended effect of preventing the pcm_multi plugin from working with jackd (or jackdmp) in duplex mode" "To make it work it's necessary to remove the linking code which was added in pcm_multi.c rev 1.89. It isn't needed here anyway. Here's a patch(http://www.sound-man.co.uk/linuxaudio/pcm_multi-patch) that removes it from alsa-lib versions 1.0.10 to 1.0.13."
Is it still true with current versions of alsa-lib?
3- Have a user interface to switch device_setup modes This may be the hardest to do and I don't think I've got the required skills to do this. Anyway, I would realy appreciate any information (or existing piece of code) about the following: * how to write a user interface which interacts with the kernel module * forcing a reinitialization of the snd-usb-audio module without unprobing/reprobing the kernel module
Thanks in advance, Thibault
At Fri, 13 Jul 2007 16:51:31 +0200, Thibault Le Meur wrote:
Hi,
For the M-Audio Audiophile USB device I still see 3 tasks that could be done to improve support under Alsa:
1- Remap the Alsa 'hardware pcm devices'
Currently:
- hw:1,0 is bound to the Analog interface in playback mode but to the
Digital interface in capture mode
- hw:1,1 is bound to the Analog interface in capture mode but to the Digital
interface in playback mode
It would be great if the one pcm device+subdevice was always linked to the same interface (Analog or Digital) Can anyone could point me to the piece of code that chooses the mapping between the device physiscal interface and Alsa's pcm interface? I'll try to see if I can fix this.
In the case of usb-audio, it's a bit complicated. The streams are assigned automatically per USB descriptions. I think the easiest would be to mangle the PCM device number in alsa-lib USB-Audio.conf file. Maybe Clemens can give a better hint.
2- Have the device able to act as a 4 channels-in + 4 channels-out combined device under Jackd I had no success in defining a multi pcm device and have it work under Jackd (but this might be a Jackd issue).
Just a question about this: in the "Multiple ICE1712 Sound Cards" tutorial, it is said that : "A change was made in alsa-lib-1.0.9rc1 which had the unintended effect of preventing the pcm_multi plugin from working with jackd (or jackdmp) in duplex mode" "To make it work it's necessary to remove the linking code which was added in pcm_multi.c rev 1.89. It isn't needed here anyway. Here's a patch(http://www.sound-man.co.uk/linuxaudio/pcm_multi-patch) that removes it from alsa-lib versions 1.0.10 to 1.0.13."
Is it still true with current versions of alsa-lib?
The problem with multi plugin and JACK was fixed on 1.0.14.
3- Have a user interface to switch device_setup modes This may be the hardest to do and I don't think I've got the required skills to do this. Anyway, I would realy appreciate any information (or existing piece of code) about the following:
- how to write a user interface which interacts with the kernel module
- forcing a reinitialization of the snd-usb-audio module without
unprobing/reprobing the kernel module
Well, the best would be to allow the driver to change the running mode on the fly without device_setup option. But this seems requring fairly big change because of the current framework of the usb-audio driver.
Takashi
It would be great if the one pcm device+subdevice was always linked to the same interface (Analog or Digital) Can anyone could point me to the piece of code that chooses the mapping between the device physiscal interface and Alsa's pcm interface? I'll try to see if I can fix this.
In the case of usb-audio, it's a bit complicated. The streams are assigned automatically per USB descriptions. I think the easiest would be to mangle the PCM device number in alsa-lib USB-Audio.conf file. Maybe Clemens can give a better hint.
Thanks for the tip... let me see have a look at this file....
Humm... at least there is something to change now : ---------------- USB-Audio.pcm.use_dmix { "AudioPhile" no # uses big-endian 24-bit samples } ----------------
==> This is not true anymore since if the device is used with device_setup=0x01 or 0x11, it supports S16_LE and thus dmix can be applied !
For the rest of the file, I definitely need Clemens' enlightenment ;-)
The problem with multi plugin and JACK was fixed on 1.0.14.
Thanks.
3- Have a user interface to switch device_setup modes This may be the hardest to do and I don't think I've got the required skills to do this. Anyway, I would realy appreciate any information (or existing piece of code) about the following:
- how to write a user interface which interacts with the kernel module
- forcing a reinitialization of the snd-usb-audio module without
unprobing/reprobing the kernel module
Well, the best would be to allow the driver to change the running mode on the fly without device_setup option. But this seems requring fairly big change because of the current framework of the usb-audio driver.
I'm afraid this is beyond my skills :-(
Let's let this for the moment... Fixing point 1 seems more important.
Thibault
Thibault Le Meur wrote:
It is taken from Pavel Polischouk's patch which wasn't really finalized (at least until now). (Pavel are you still reading to this list?)
I had no time to play around or fix my old patches, or even to read this list, for quite some time. Feel free to incorporate any part of my patch into the tree, I won't be able to participate in the development in any way for at least several months.
Regards, Pavel
At Tue, 04 Sep 2007 18:18:45 -0400, Pavel Polischouk wrote:
Thibault Le Meur wrote:
It is taken from Pavel Polischouk's patch which wasn't really finalized (at least until now). (Pavel are you still reading to this list?)
I had no time to play around or fix my old patches, or even to read this list, for quite some time. Feel free to incorporate any part of my patch into the tree, I won't be able to participate in the development in any way for at least several months.
OK, Thilbault, could you post the latest version for merge?
Thanks,
Takashi
participants (4)
-
Hakan Lennestal -
Pavel Polischouk -
Takashi Iwai -
Thibault Le Meur