Hi Kunal, Thanks for the info. I'll try this in a few minutes. I forgot to mention in my post that there is another oddity. The code works fine if I use the internal microphone but when I set the input source to line in the preferences panel is when I get the error. The error appears to be in the render function. Certainly when I compile the code there are deprecated references, but I don't think they are the source of the problem. It is curious that the line input has different functionality than the microphone. I hope your fix works cuz I'm showing this stuff off this weekend. Chris
On Thu, Sep 8, 2011 at 4:03 PM, Kunal Kandekar <[email protected]>wrote: > 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 > > > On Thu, Sep 8, 2011 at 7:48 AM, chris lirakis <[email protected]> wrote: > >> 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 >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > -- Chris Lirakis
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
