Audio over serial connection
GaryT
Posts: 11
Hello all, I'm not an electronics expert and I'm very new to the Propeller, but I have been using Stamps for a while.
I'm wondering if there is a way, and hopefully and example, of how to take microphone-in data and stream it in a normal serial fashion to another Propeller chip's headphone-out pin? I've been playing with some of the microphone examples and the Demo board like microphone_to_VGA (which is pretty cool) and microphone_to_headphones and it seems like it's possible, any pointers?
Thanks,
Gary
I'm wondering if there is a way, and hopefully and example, of how to take microphone-in data and stream it in a normal serial fashion to another Propeller chip's headphone-out pin? I've been playing with some of the microphone examples and the Demo board like microphone_to_VGA (which is pretty cool) and microphone_to_headphones and it seems like it's possible, any pointers?
Thanks,
Gary
Comments
So:
microphone_to_VGA writes sample to a hub variable "adcsample"
adcsample is read and transmitted as bytes with some kind of word synch by a modified serial object
hub variable is "wiped" or set to some impossible value to indicate that it has been read
( there is no need to buffer more than one sample as this is a continuous transmission stream and the whole thing needs to stay in synch)
The receiving serial object re-assembles the bytes back into a sample which could be fed directly to the "DAC" output using just the same cog.
Sounds simple but I suggest that you play with the microphone_to_vga object simply because it's a good starting point plus you can always see what the system is processing. Both Rayman and epmoyer to name some names have done excellent work with Prop audio although epmoyer's stuff uses a codec (but a Propeller CPU none the less). I will be ready to actually test some real software soon when I get my pcbs back. The pcb allows for Propeller Audio to Digital and Digital to Audio using dual sampling frequencies as well as the optional CODEC so I'm sure I can release some general-purpose code then.
*Peter*
Thanks Guys!
Gary
I always wondered... What exactly is "HQ audio"?
I also always wondered what exactly is "THX" audio, and then I found out: THX: This is all there is to it!
Video here: mydancebot.com/viewport/videos.php
I think HQ Audio would mean "High Quality Audio" High quality is based on sample rate and frequency range. THX is a standard of sorts for ensuring an audio system meets certain requirements for power level and frequency response.
A while ago there was a forum post on sending data using fiber optics. Perhaps the mic propeller could use the a half-duplex and set up an optical link to the other Propeller. Maybe it was Rayman that setup the optical link, I can't recall for sure.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com
<rant deleted about my knowledge and experiences
involving trademarked proprietary imaginary features
that have insulted my intelligence, but not fooled me.>
Hi Virand,
[noparse][[/noparse]rant]
I was recently working for a video technology company (Anchor Bay Technologies), and one of the projects I was working on was a home theater video processor that featured THX Certification (it's currently the only video processor with the THX Certification on the market). THX Ltd., as a company can do a few things:
Sorry if this is the type of "proprietary imaginary features that have insulted (your) intelligence", but having people who don't understand something bash it, insults people like me... I spent over a month going back a forth from THX's Lab to my company's Lab calibrating just the analog video output stage in the DVDO iScan VP50PRO to meet their very tight reference level requirements (+/-1.5mV between YPbPr signals and +/-1.5mV from the industry standard levels {over a 1Vp-p range signal} - this is tighter that most reference test pattern generators can do). THX doesn't actually have a "feature" or "product", but rather they are more like a regulating body (in fact the only physical product that i'm aware of from THX is the old "R2" audio analyzer unit).
[noparse][[/noparse]/rant]
Gary,
One of the risks with serializing audio on one chip and de-serializing on another is that the audio has to be output at exactly the same rate as it was taken in, or it affects the audio (remember that a sample is a voltage at a point in time relative to another voltage at another specific point in time - altering either affects the amplitude or frequency respectively). Having worked on products that have to take audio from one chip to another - might I suggest the I2S interface? (stands for "Inter IC Sound", IIS, I2S). Between HDMI chips, it's common to find an I2S bus for audio in CE products but they have a few extra lines so that they can support up to 8-channels.
The I2S interface is a stereo interface with 64-bits per sample period (32-bits per channel). There can be 4-lines to carry the data:
1) an optional Master "super" clock (for operations like sample rate conversion - must be 128, 256, or 512x the sample rate)
2) a Bit Clock (64x the sample rate)
3) a "L/R" (Channel) Clock (2x the sample rate)
4) a Data-line (this carries the sample data for both channels)
Pro's for I2S:
Con's for I2S:
The reason I suggest the I2S interface method, is that if you use a single line serial interface, you can get jitter (which may be audible if it's in the right range) which could produce "wow and flutter" (there's a term from the old analog tape days... where the speed of the output can accelerate and decelerate causing the pitch to change noticeably). You may try doing an S/PDIF (Sony/Philips Digital InterFace) for audio - which embeds a clock with the data with simple polarity agnostic biphase marked encoding (clock is 2x the bit clock rate, the samples contain 64-bits per sample period, and 192 Frames per block). I shy away from single line interfaces in SW because you really need dedicated PLLs to get the audio samples exactly where they should be at the output (it's easier to get close with I2S, and a fast enough processor). The problem with interfaces like S/PDIF, is that the specifications are not free... (see AES3-2003 for the hardware interface, and IEC60958-3 for the "Consumer" encoding of PCM audio within the interface).
[noparse][[/noparse]joking] Who knows - maybe you'll end up making a product that THX might be able to certify, and they'll give you one of these to put in front of your TV [noparse][[/noparse]/joking]
Post Edited (GreyBox Tim) : 11/22/2008 6:26:08 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com
"THX: This is all there is to it!" - You forgot the plug-in COWS -
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.