Hi,
I've been having problems with the audio on OSX as well. Ever since 10.5, really. I am not sure what the cause is... maybe the code in audio_osx_source.cc is incompatible with changes in the OSX audio frameworks that may have occurred under the hood.
However, I currently have a really, really horrible hack that works for some reason: I run a Java app that does nothing but open up an audio source line, close it and shut down. After that I have no trouble with any of the gr audio osx blocks. (I had some Java audio recording code lying around, which I rewrote to pipe audio into GNU Radio over a socket as a quick replacement for the gr audio_osx_source block, and I accidentally discovered that the block started working after I ran the Java app.)
I suspect there is something in CoreAudio (or AudioUnit?) that must be initialized that audio_osx_source is not doing, but somehow the Java app does it. I am at a loss to explain how this persists even after the Java app terminates. The fix persists until you reboot the machine.
In case you want to give it a shot, I've attached the Java source. Compile it with "javac AudioSource.java" and run it with "java AudioSource localhost 6666 44100 mic 16 2". It will exit with an error saying it cannot connect to a socket, but it should have worked its magic anyway. If it works, you should be able to use audio_osx_source with no problems. It would be very interesting to see if it works for you.
I've been meaning to dig into the audio_osx_source code and OSX audio internals to figure out the bug, but haven't had time. There are a few other problems that need fixing as well (e.g. device_name is not properly used).
Kunal
This appears to be an issue with OSX 10.6. This can be replicated by running the python audio_fft.py example.
Searching the web for the error message I find the apple experts saying that this results from the expectation that a sample rate conversion will occur. Not being well versed in OSX audio internals I don't know exactly what that means. I assume that it means that the audio input and output rates are different.
My first question is, has anyone else seen this and has it been fixed and I am not aware of it?
So I'm slowly looking through gr_audio_osx/src/audio_osx_source.cc and trying to understand what is going on. Now my second question.
I did the install using macports but I also have a copy the source of gnuradio-3.3.0 and have compiled it. I have tried putting some debugging info in the source and recompiling. I subtituted both the .la and .dyib libraries produced. My print statements do not appear.
I am assuming that the python audio interface is a dynamically linked object and substitution of my library should work. Is this a false assumption? Is there a better way I can debug this?
Regards,
Chris
--
Chris Lirakis
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio