After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 711764 - osxaudiosrc: Produces broken audio for any sample rate other than 44100Hz
osxaudiosrc: Produces broken audio for any sample rate other than 44100Hz
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Mac OS
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 740987
Blocks:
 
 
Reported: 2013-11-10 08:50 UTC by Elio Francesconi
Modified: 2015-07-19 14:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Elio Francesconi 2013-11-10 08:50:59 UTC 
On iOS platforms the caps returned by  osxaudiosrc is not properly set and returns the default one value instead of the correct one.
This issue causes a distorted audio with this pipeline where a conversion is needed:
osxaudiosrc ! audioconvert ! audioresample ! alawenc ! rtppcmapay ! udpsink host=192.168.1.6 port=5011


To reproduce the issue I modified the tutorial2 using the pipeline above and start on a linux client the script: ./client-PCMA.sh
Comment 1 Sebastian Dröge (slomo) 2013-11-11 09:42:34 UTC 
I can confirm that here, works fine when using Speex.
Comment 2 Sebastian Dröge (slomo) 2013-11-11 09:47:35 UTC 
Workaround is the following:

osxaudiosrc ! capsfilter caps=audio/x-raw,rate=44100 ! audioconvert ! audioresample ! alawenc ! rtppcmapay ! udpsink host=192.168.1.6 port=5011
Comment 3 Sebastian Dröge (slomo) 2013-11-11 10:17:55 UTC 
Might be because audio is a shared resource on iOS, and it only provides the audio in one sample rate. Independent of what we set.
Comment 4 Robert Swain 2014-08-07 12:26:43 UTC 
This also affects Mac OS X. For example:

GST_DEBUG=2 gst-launch-1.0 osxaudiosrc ! audio/x-raw,format=S32LE,rate=48000,layout=interleaved ! audioconvert ! osxaudiosink

Spits a lot of:

0:00:00.082529000 52000    0x101a27f80 WARN             osxaudiosrc gstosxaudiosrc.c:288:gst_osx_audio_src_io_proc:<osxaudioringbuffer1> AudioUnitRender returned -10863

It seems to be something along the lines of what is suggested in comment 3. According to https://developer.apple.com/library/ios/documentation/AudioUnit/Reference/AUComponentServicesReference/Reference/reference.html an error return of -10863 has a key of kAudioUnitErr_CannotDoInCurrentContext . A bit of searching about that seems to suggest topics of setting various things on the device instead of the AudioUnit HAL or about the sharing of devices.
Comment 5 Arun Raghavan 2014-12-01 15:58:22 UTC 
This should be fixed by the patches in bug #740987.
Comment 6 Marcin Lewandowski 2015-07-19 14:19:52 UTC 
There seems to be regression.

I was able to trigger this bug with GSt 1.4.5 on two macbook airs with Mac OS X 10.10.4.

I am getting in the log

0:03:01.979935000 62211    0x100703ac0 WARN             osxaudiosrc gstosxaudiosrc.c:288:gst_osx_audio_src_io_proc:<osxaudioringbuffer0> AudioUnitRender returned -10863
Comment 7 Arun Raghavan 2015-07-19 14:23:04 UTC 
Do you have an example pipeline to generate that?