Recording strangeness with OpenAL-Soft 1.8.466

[Troy Yee]

Hi All.

Has anyone noticed any problems capturing using OpenAL-Soft 1.8.466 on
Linux?  I am currently looking into possible causes (including test
environment weirdness).  The short of it is that a simple app that
captures from the default capture device and writes captured samples to
the default playback device has different behaviour when used with a
previous instance of OpenAL-Soft (1.4.272 perhaps? which was correct).
When LD_LIBRARY_PATH is set to point to older library, all is fine.
When set to point to new library, the playback sounds like it is faster
than it should be (speech sounds almost chipmunk-like but broken).
Capture and playback rates are being specified and match.

Platform is SuSE Linux Enterprise Desktop (SLED) 10.1 sp 1
Compiled with ALSA support.

(sorry, I don't have the code immediately available but can get it... it
is basically something I found on the web as an example)

Troy.

_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

[Chris Robinson-5]

On Wednesday 01 July 2009 10:09:04 am Troy Yee wrote:

> Has anyone noticed any problems capturing using OpenAL-Soft 1.8.466 on
> Linux?  I am currently looking into possible causes (including test
> environment weirdness).  The short of it is that a simple app that
> captures from the default capture device and writes captured samples to
> the default playback device has different behaviour when used with a
> previous instance of OpenAL-Soft (1.4.272 perhaps? which was correct).
> When LD_LIBRARY_PATH is set to point to older library, all is fine.
> When set to point to new library, the playback sounds like it is faster
> than it should be (speech sounds almost chipmunk-like but broken).
> Capture and playback rates are being specified and match.

Hi.

It would be very helpful to paste a small test app (with code) that shows the
error. The only thing of note is that newer versions are more careful about
opening the capture device with the precise capture rate given (as the OpenAL
capture spec requires). This shouldn't break apps, though.. at least none that
aren't already broken.

It may be helpful to say which device is actually being used, by calling
alcGetString(device, ALC_CAPTURE_DEVICE_SPECIFIER);
on the opened capture device (for both 1.4 and 1.8). Would also be helpful to
know if PulseAudio is installed/active, or if you're using the aoss script.
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

[Troy Yee]

Hi Chris:

Thanks for  your response.  The developer I have looking into this has reported the following:

In alsa.c: ALCboolean alsa_open_capture(..) function, in line 632 and 658, the third passed in argument for psnd_pcm_hw_params_set_format should be alsaFormat, instead of data->format as alsaFormat is the format that the caller specified when trying to open the capture device.

Looking at alsa_open_playback, an update was done by replacing/renaming alsaFormat with data->format, and pass data->format into psnd_pcm_hw_params_set_format.  I believe they probably just missed the same update in alsa_open_capture(..).

I don't have access to the code at the moment so I haven't been able to confirm the conclusion.

Troy.


----- Original Message -----
From: Chris Robinson <chris.kcat@...>
Date: Wednesday, July 1, 2009 19:28
Subject: Re: [Openal] Recording strangeness with OpenAL-Soft 1.8.466
To: openal@...

> On Wednesday 01 July 2009 10:09:04 am Troy Yee wrote:
> > Has anyone noticed any problems capturing using OpenAL-Soft
> 1.8.466 on
> > Linux?  I am currently looking into possible causes
> (including test
> > environment weirdness).  The short of it is that a simple
> app that
> > captures from the default capture device and writes captured
> samples to
> > the default playback device has different behaviour when used
> with a
> > previous instance of OpenAL-Soft (1.4.272 perhaps? which was
> correct).> When LD_LIBRARY_PATH is set to point to older
> library, all is fine.
> > When set to point to new library, the playback sounds like it
> is faster
> > than it should be (speech sounds almost chipmunk-like but broken).
> > Capture and playback rates are being specified and match.
>
> Hi.
>
> It would be very helpful to paste a small test app (with code)
> that shows the
> error. The only thing of note is that newer versions are more
> careful about
> opening the capture device with the precise capture rate given
> (as the OpenAL
> capture spec requires). This shouldn't break apps, though.. at
> least none that
> aren't already broken.
>
> It may be helpful to say which device is actually being used, by
> callingalcGetString(device, ALC_CAPTURE_DEVICE_SPECIFIER);
> on the opened capture device (for both 1.4 and 1.8). Would also
> be helpful to
> know if PulseAudio is installed/active, or if you're using the
> aoss script.
> _______________________________________________
> Openal mailing list
> Openal@...
> http://opensource.creative.com/mailman/listinfo/openal
>

_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

[Chris Robinson-5]

On Thursday 02 July 2009 4:21:31 pm Troy Yee wrote:

> In alsa.c: ALCboolean alsa_open_capture(..) function,
> in line 632 and 658, the third passed in argument for
> psnd_pcm_hw_params_set_format should be alsaFormat, instead of
> data->format as alsaFormat is the format that the caller specified
> when trying to open the capture device.
>
> Looking at alsa_open_playback, an update was done by
> replacing/renaming alsaFormat with data->format, and pass
> data->format into psnd_pcm_hw_params_set_format.  I believe they
> probably just missed the same update in alsa_open_capture(..).I don't have
> access to the code at the moment so I haven't been able to confirm the
> conclusion.

Thanks for spotting that. It was indeed a copy-paste error. I have that fixed
in GIT/SVN, now. There was also another bug causing it to not fallback to non-
mmap capture properly.
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal