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 fg.start() 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. Kunal On Thu, Sep 8, 2011 at 8:03 PM, chris lirakis <[email protected]> wrote: > 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 > >
server_src.py
Description: Binary data
AudioSource.java
Description: Binary data
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
