Hi Bruce and all, First, "SmallDV" only uses ONE audio device. As marked on the device, Mic in, Headphones out.
Matt uses a relay outside to swap things when in Transmit mode. But, in this world of consumer goods, you get what you pay for. Tested thus far: Working well =========== Creative Sound Blaster Play! not available, superceded Creative Sound Blaster Play! 3 the current model, available ID = 0: "hw:Sound Blaster Play! 3,0" VOLANDS VL-UA01 From PC shop, inexpensive ID = 0: "hw:USB Audio Device,0" Poor ==== C-Media C119 clones Virtual 7.1Ch Sound, with Mute, Up & Down vol switches, red and green LEDS. (all six bought in 2011) We are using the device in Full Duplex, simultaneous audio in and audio out. Yes I understand the problem with two audio devices with different clocks. With the above testing, it's not the Linux driver but the firmware/hardware of the cheaper device causing problems. lsusb ID 0d8c:0014 C-Media Electronics, Inc. the VOLANS Chipset: ASMedia (HS100-B) ID 041e:324d Creative Technology, Ltd the Play! 3 There we have it, the Play! 3 is the best and at $35AU is not outrageous. Alan VK2ZIW On Mon, 18 Feb 2019 11:21:40 -0800, Bruce Perens wrote > I should reiterate the problem, just to make sure everyone understands what > is happening. When you use two audio devices with different clocks, one will > inevitably run faster than the other. The result is that over time, be it > minutes, hours, or days, you will either develop a lag in processing and fill > up your buffers until you run out of space, or you will go to your input > device for samples and there will be less than you expect or none. > > Your software must handle this, unless you have custom hardware like SDR1000 > where all of the audio devices all run off of one clock. It must deal with > both over-runs and under-runs. Until you do this, using two audio devices > means that at some point, be it minutes, hours, or days, your software will > break. > > Handling output overruns means that you will throw away some samples once in > a while to resynchronize. If you can tell when your output device is still > processing samples when it should not be, you can do this gracefully so that > nobody will hear it by throwing away every 100th output sample or something > similar. > > Handling input underruns is similar. If you can tell it's happening, you can > duplicate every 100th input sample to get a longer input buffer, or something > similar. > Of course you can get fancy and interpolate. > > > If you can't tell what your device is doing until a read or write fails, you > have to throw away a whole buffer and this will result in a click. > > Thanks > > Bruce > Alan Evil flourishes when good men do nothing. Consider the Christmas child. --------------------------------------------------------------------------- Alan Beard Unix Support Technician from 1984 to today 70 Wedmore Rd. Sun Solaris, AIX, HP/UX, Linux, SCO, MIPS Emu Heights N.S.W. 2750 Routers, terminal servers, printers, terminals etc.. +61 2 47353013 (h) Support Programming, shell scripting, "C", assembler 0414 353013 (mobile) After uni, electronics tech
_______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
