I think maybe it could be a good idea to have the audiostream keep track of current sample being asked to render. Currently if you do play(SinOsc()) and then play(SinOsc()) again, the two oscillators will have arbitrary phase between them. For the quadrature demodulation, I needed 90°phase shift between two SinOsc nodes, so that was my use-case.
Other than that, actually, I didn't need much else. I did write a lot of code that I ended up not using as I started to understand AudioIO better. For example, I changed the FIR filter node ( https://github.com/ssfrr/AudioIO.jl/issues/25) to take its input through the device_input argument, and so to use it I had to make a ComposeNode function, which attaches two nodes in series. But I don't think this was actually a good change, and I think that maybe inputs to a node should be passed to the constructor as is the current design. On Thu, Nov 20, 2014 at 2:42 AM, Spencer Russell < [email protected]> wrote: > Whoa, awesome stuff! > > Do you have a sense yet for what would be a good candidate for merging > into AudioIO and what's going to be split into a separate package? > > > On Tuesday, November 18, 2014 10:46:25 PM UTC-5, Gustavo Goretkin wrote: >> >> Old thread, but I've implemented a streaming encoder/decoder for FSK >> bauddot (used for example for TTY/TDD over telephone lines). I used the >> excellent AudioIO and Multirate packages. The implementation is currently >> baked into my fork of AudioIO >> >> https://github.com/goretkin/AudioIO.jl >> >> You can run the following example: >> >> julia> include("examples/tty_full.jl") >> INFO: Initializing PortAudio. Expect errors as we scan devices >> INFO: Scheduling PortAudio Render Task... >> hooked up receiverINFO: PortAudio Render Task Running... >> >> WARNING: Phase Noise: 1.5707963705062866 >> hooked up transmitterWARNING: Phase Noise: 1.5707963705062866 >> >> >> julia> BEEP BOOP BEEP BEEP BEEP. >> >> where the string is being decoded from the tones generated from the >> speaker and received by the mic. If you can get a good connection to the >> telephone network (I coupled acoustically with earphones on my cellphone in >> TTY mode), you can also communicate with TDD devices. >> >> On Tuesday, April 8, 2014 3:17:26 PM UTC-4, Kaj Wiik wrote: >>> >>> >>> >>> On Tuesday, April 8, 2014 5:43:05 AM UTC+3, Jay Kickliter wrote: >>>> >>>> You're absolutely right tagging, but have no intention of turning Radio >>>> into a streaming processing framework. My inspiration is LiquidDSP >>>> <http://liquidsdr.org> and Matlab's communications toolbox. If liquid >>>> wasn't GPL, I would just write an interface to it. It can be compiled >>>> without any dependancies, and has phenomenal documentation. >>>> >>> >>> Hmm, there is GSL.jl and GSL is GPL (and in fact also FFTW), I guess >>> there are no legal problems in writing an interface (unless you plan to use >>> it in a closed source software). >>> >>> Very interesting thread, a lot of good work, I'd very much like to see >>> the RTLSDR interface :-)... >>> >>> Cheers, >>> Kaj >>> >>>
