[alsa-devel] Recording devices opened mono still sending stereo causing corrupt audio
(Re-sending including alsa-devel and more information.)
Hello there.
I'm a developer for Mixxx, the cross-platform open-source DJ software which uses PortAudio and we've been trying for a long time to track down the cause of "horrible mic sound" as documented in our bug: https://bugs.launchpad.net/mixxx/+bug/900364 The resulting recorded audio sounds about 50-60% lower pitch with crackles and it only happens with the ALSA API on Linux and only with certain (mostly Intel-based) audio devices.
I have just discovered by testing in Audacity (which also uses PA) that the problem occurs when PA (and therefore ALSA) is asked to open just one channel of a sound input device yet the device (or ALSA) seems to stream two anyway. I have been able to reproduce the problem in Audacity (which also uses PA) when selecting the ALSA API and mono recording, but it works correctly when I change it to stereo recording.
I'm suspecting there's a miscommunication between PA and ALSA or ALSA and the sound hardware where either the lower level is saying its input(s) can only be opened in stereo and the higher level (or the application above it) ignores that, or the lower level says it's fine opening mono but then misbehaves.
How can I find out which, whether it's ALSA, PA, or the sound hardware at fault?
Sincerely, Sean M. Pappalardo "D.J. Pegasus" Mixxx Developer - Controller Specialist
Sean M. Pappalardo - D.J. Pegasus wrote:
the problem occurs when PA is asked to open just one channel of a sound input device yet the device seems to stream two anyway.
Many devices do not support mono streams.
I'm suspecting there's a miscommunication between PA and ALSA
The communication between ALSA and PA works just fine; ALSA reports the minimum number of channels, and PA saves this value.
What does not work is the communication between PA and the application; PA has no mechanism to report the minimum number of channels.
Even worse, if some application tries to use a channel count that is too low, PA cleverly replaces it with the minimum support channel count:
self->numHostChannels = PA_MAX( params->channelCount, StreamDirection_In == streamDir ? devInfo->minInputChannels : devInfo->minOutputChannels );
and then does not bother to tell anybody about this.
This bug is especially egregious because PA does later check whether the number of channels is actually supported by the device; the code above ensures that this checks uses the wrong channel number.
Regards, Clemens
On Friday 11 October 2013 13:33, Clemens Ladisch wrote:
Sean M. Pappalardo - D.J. Pegasus wrote:
the problem occurs when PA is asked to open just one channel of a sound input device yet the device seems to stream two anyway.
Many devices do not support mono streams.
I'm suspecting there's a miscommunication between PA and ALSA
The communication between ALSA and PA works just fine; ALSA reports the minimum number of channels, and PA saves this value.
What does not work is the communication between PA and the application; PA has no mechanism to report the minimum number of channels.
Even worse, if some application tries to use a channel count that is too low, PA cleverly replaces it with the minimum support channel count:
self->numHostChannels = PA_MAX( params->channelCount, StreamDirection_In == streamDir ? devInfo->minInputChannels
: devInfo->minOutputChannels );and then does not bother to tell anybody about this.
This bug is especially egregious because PA does later check whether the number of channels is actually supported by the device; the code above ensures that this checks uses the wrong channel number.
Thanks for the comments, Clemens. Do USB devices typically not support mono, or is it various, by specific unit?
I think the intention would be that in these cases Portaudio would do channel adaption between the stereo host stream and the mono stream passed to the user. It may well be that the Alsa implementation is not doing that correctly.
However, shouldn't the Alsa default device allow a mono stream to be opened on a stereo-only device? I was hoping some additional test info would narrow down the area where the problem lies, before going too deep into the Portaudio code!
Regards
Alan
Alan Horstmann wrote:
On Friday 11 October 2013 13:33, Clemens Ladisch wrote:
Sean M. Pappalardo - D.J. Pegasus wrote:
the problem occurs when PA is asked to open just one channel of a sound input device yet the device seems to stream two anyway.
Many devices do not support mono streams.
Do USB devices typically not support mono, or is it various, by specific unit?
Many USB device do support mono (especially those with microphones).
It is all motherboard devices that do not support mono.
However, shouldn't the Alsa default device allow a mono stream to be opened on a stereo-only device?
Yes, the device named "default" allows this.
What is PA's default device name?
Regards, Clemens
On 11/10/2013 11:33 PM, Clemens Ladisch wrote:
Sean M. Pappalardo - D.J. Pegasus wrote:
the problem occurs when PA is asked to open just one channel of a sound input device yet the device seems to stream two anyway.
Many devices do not support mono streams.
I'm suspecting there's a miscommunication between PA and ALSA
The communication between ALSA and PA works just fine; ALSA reports the minimum number of channels, and PA saves this value.
What does not work is the communication between PA and the application; PA has no mechanism to report the minimum number of channels.
Since PortAudio is designed to provide useful features to the client, it does not make sense to restrict the client from opening a stereo device as mono.
This is by design.
However obviously there is an implementation issue in PA/ALSA if it does not respect ALSA's interface requiring support for a minimum number of channels > 1.
In this case PortAudio should either select the first (left) channel or downmix to mono before passing to the client. I'd suggest the former. (or in general min(userRequestedChannelCount,availableChannelCount)
Even worse, if some application tries to use a channel count that is too low, PA cleverly replaces it with the minimum support channel count:
self->numHostChannels = PA_MAX( params->channelCount, StreamDirection_In == streamDir ? devInfo->minInputChannels : devInfo->minOutputChannels );
and then does not bother to tell anybody about this.
The implementation should be dropping the second channel. So it should be telling the PA buffer processor to do so.
This bug is especially egregious because PA does later check whether the number of channels is actually supported by the device; the code above ensures that this checks uses the wrong channel number.
Thanks for your input,
Ross.
Regards, Clemens
bcc: alsa-devel
Excellent -- glad to see it's as simple as a fix to the ALSA hostapi! Is anyone from the PA side interested in picking this up or should we work on a patch? We'd like to fix this for good in our next major release (early 2014?) so it would be good to try and get this into a PA release soon so we can get it packaged in the various distros.
Best regards, RJ
On Fri, Oct 11, 2013 at 9:05 PM, Ross Bencina rossb-lists@audiomulch.comwrote:
On 11/10/2013 11:33 PM, Clemens Ladisch wrote:
Sean M. Pappalardo - D.J. Pegasus wrote:
the problem occurs when PA is asked to open just one channel of a sound input device yet the device seems to stream two anyway.
Many devices do not support mono streams.
I'm suspecting there's a miscommunication between PA and ALSA
The communication between ALSA and PA works just fine; ALSA reports the minimum number of channels, and PA saves this value.
What does not work is the communication between PA and the application; PA has no mechanism to report the minimum number of channels.
Since PortAudio is designed to provide useful features to the client, it does not make sense to restrict the client from opening a stereo device as mono.
This is by design.
However obviously there is an implementation issue in PA/ALSA if it does not respect ALSA's interface requiring support for a minimum number of channels > 1.
In this case PortAudio should either select the first (left) channel or downmix to mono before passing to the client. I'd suggest the former. (or in general min(userRequestedChannelCount,**availableChannelCount)
Even worse, if some application tries to use a channel count that is too
low, PA cleverly replaces it with the minimum support channel count:
self->numHostChannels = PA_MAX( params->channelCount, StreamDirection_In == streamDir ? devInfo->minInputChannels : devInfo->minOutputChannels );
and then does not bother to tell anybody about this.
The implementation should be dropping the second channel. So it should be telling the PA buffer processor to do so.
This bug is especially egregious because PA does later check whether the
number of channels is actually supported by the device; the code above ensures that this checks uses the wrong channel number.
Thanks for your input,
Ross.
Regards, Clemens
______________________________**_________________ Portaudio mailing list Portaudio@music.columbia.edu http://music.columbia.edu/**mailman/listinfo/portaudiohttp://music.columbia.edu/mailman/listinfo/portaudio
On Friday 11 October 2013 02:40, Sean M. Pappalardo - D.J. Pegasus wrote:
I'm a developer for Mixxx, the cross-platform open-source DJ software which uses PortAudio and we've been trying for a long time to track down the cause of "horrible mic sound" as documented in our bug: https://bugs.launchpad.net/mixxx/+bug/900364 The resulting recorded audio sounds about 50-60% lower pitch with crackles and it only happens with the ALSA API on Linux and only with certain (mostly Intel-based) audio devices.
I have just discovered by testing in Audacity (which also uses PA) that the problem occurs when PA (and therefore ALSA) is asked to open just one channel of a sound input device yet the device (or ALSA) seems to stream two anyway. I have been able to reproduce the problem in Audacity (which also uses PA) when selecting the ALSA API and mono recording, but it works correctly when I change it to stereo recording.
I'm suspecting there's a miscommunication between PA and ALSA or ALSA and the sound hardware where either the lower level is saying its input(s) can only be opened in stereo and the higher level (or the application above it) ignores that, or the lower level says it's fine opening mono but then misbehaves.
How can I find out which, whether it's ALSA, PA, or the sound hardware at fault?
As one of those involved with Portaudio-Alsa, I have had a read through the Mixx bug record (900364). I don't have any immediate candidates for the cause, but here are a number of suggestions/questions that may help 'close in' on the problem; any of these may give more insight.
Is the trouble ALWAYS associated with a duplex stream - ie does the Mic always record fine when there is no simultaneous output to the same device? It may be that Portaudio is mis-handling this case, mono input with stereo output.
Look at un-compressed bad recording (perhaps with Audacity) - are the samples obviously duplicated (each level twice)? Perhaps post a short wav (1 sec) or a screen shot. The compressed files don't show this, but may be smoothing it out.
Is Pulseaudio running on these systems? If so, try with that disabled (pasuspender...) - in fact, for testing it is best to eliminate any effects it may introduce unless it is implicated.
What Portaudio devices does this occur with? Is it only default/sysdefault, or with the 'hw' devices?. If the hw ones, try setting the environment variable PA_ALSA_PLUGHW to 1 before running the Mixx app in a terminal and report if there is any change - that will enable channel adaption in Alsa.
Build the app with Portaudio debug enabled ( --enable-debug-output or define PA_ENABLE_DEBUG_OUTPUT) and see the terminal output. Perhaps post it in non-working case.
Build Portaudio stand-alone and run the test/example program pa_devs on the troublesome system so we can see how the capabilities are reported.
There may be issues with how different Alsa soundcard drivers treat mono microphone inputs. Some may output the same data to both channels, and return twice as much data as expected. Pulseaudio, if operating, may also do copying.
Hope this gives some avenues to pursue!
Regards
Alan
participants (5)
-
Alan Horstmann -
Clemens Ladisch -
RJ Ryan -
Ross Bencina -
Sean M. Pappalardo - D.J. Pegasus