[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] OSX Audio Problem - AudioUnitRender kAudioUnitErr
Re: [Discuss-gnuradio] OSX Audio Problem - AudioUnitRender kAudioUnitErr_CanNotDoInCurrentContext
Thu, 8 Sep 2011 22:32:36 -0400
Hmm, I haven't tried this with the line-in input, although I have previously had problems using line-in on older versions of OS X and/or GNU Radio.
If it doesn't work, one option is to try the hack that I was trying - capture audio in Java (or any other language) and pipe it to GNU Radio over a socket. Attached is a modified version of the Java code that lets you select an audio input line. Compile using "java AudioSource.java" as before, and run using:
java AudioSource <host> <port> [samplerate] [line] [bits/sample] [channels]
The [line] option is a number identifying the audio line you want to use. Try numbers 0, 1, etc. (the code lists all available lines when you run it regardless of the value of [line].) One of the available lines *should* be the line-in. E.g. -
clear; java AudioScope localhost 6666 44100 1 16 1
Also attached is a Python script implementing a GR hierarchical block that starts a TCP server socket and accepts a connection from an external (Java) process. You can then connect it to a flowgraph like any other GR source block. E.g.
from server_src import server_src
audio_src = server_src(gr.sizeof_float, 6666, 'localhost')
fg.connect(audio_src, other_blocks, ...) # fg is your flowgraph
audio_src.start() # must call start to accept connection else script will hang
Make sure you start the GR flowgraph before you start the Java process. It's a awkward hack, but it's worked for me so far... Hope this helps.
On Thu, Sep 8, 2011 at 8:03 PM, chris lirakis <address@hidden>
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.
On Thu, Sep 8, 2011 at 4:03 PM, Kunal Kandekar <address@hidden>
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).
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?
Discuss-gnuradio mailing list
-- Chris Lirakis
Description: Binary data
Description: Binary data