Shop OBEX P1 Docs P2 Docs Learn Events
Audio over serial connection — Parallax Forums

Audio over serial connection

GaryTGaryT Posts: 11
edited 2008-11-19 17:14 in Propeller 1
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

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2008-11-17 01:06
    It's certainly possible over short distances (because of the data rate needed). You'd need to rewrite the microphone_to_headphones routine to put samples in a buffer which would be processed by a half-duplex version of the FullDuplexSerial driver that you'd have to write using the existing one as a model. Similarly, you'd need the receive end of the FullDuplexSerial driver reading into a buffer that would be processed by the output side of the microphone_to_headphones routine at a fixed rate.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2008-11-17 01:09
    I am amongst other things doing a bit with audio recording, transmission, and playback at present although I am relying on an external codec for the HQ audio. Can I suggest that for starters you take the microphone_to_VGA demo and modify it just a little to also save the current sample to a hub variable which can be read by a modified FullDuplexSerial object to output samples as groups of bytes. Of course there are better objects for high-speed serial but you should be able to start with this.

    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*
  • GaryTGaryT Posts: 11
    edited 2008-11-17 03:27
    Thanks Mike and Peter for the ideas! I'll start with the microphone code. Maybe I should check into CODECs? I'll have to see what Rayman and epmoyer are up to....

    Thanks Guys!
    Gary
  • VIRANDVIRAND Posts: 656
    edited 2008-11-17 06:18
    ...
    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!
  • HannoHanno Posts: 1,130
    edited 2008-11-17 07:36
    ViewPort has a tutorial that streams audio samples to the PC. There it's graphed in an Oscilloscope view and a spectrum analyzer. At 2mbps, you can send 50,000 samples/sec at 32bits each.... Should be enough for HQ!
    Video here: mydancebot.com/viewport/videos.php
  • Timothy D. SwieterTimothy D. Swieter Posts: 1,613
    edited 2008-11-18 01:23
    Virand -

    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
  • VIRANDVIRAND Posts: 656
    edited 2008-11-18 02:06
    Ok, thanks for the info... re HQ and THX
    <rant deleted about my knowledge and experiences
    involving trademarked proprietary imaginary features
    that have insulted my intelligence, but not fooled me.>
  • GreyBox TimGreyBox Tim Posts: 60
    edited 2008-11-19 06:57
    VIRAND said...

    <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:
    • Ensure that a video and audio stream conforms to a standardized process (like ensuring color quality, audio dynamic range and dialog intelligibility) on the post-production side
    • Ensure that a compressed data stream for video has a properly formatted data payload, and meta-data that correctly identifies the data payload to downstream devices
    • Ensure that playback devices and all other devices placed in the signal path from storage to final "presentation" (screen surface, speaker output), do not adversely alter the data that was stored (this can happen a lot, trust me!!)
    • Ensure that the viewing environment is calibrated to the reference standard that the content was mastered in (giving the director/producer's intended rendering of the content to the user).
    • Publish standards for how things should be done, so that companies can follow them and things work well together
    • Test and certify products against the standard, then publish the list of certified products so that customers and installers can find products that will function as expected.
    • Advocate for processes/standards in the industry so that products work better together

    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:
    • Well documented (thanks to Philips - now NXP), industry standard audio interface - works with a lot of chips out there (including cheap D/A Converters...)
    • Because of master-clock, bit-clock, channel-clock, the downstream chip can tell exactly where a sample should be used (the downstream chip doesn't get to make decisions about how fast to output the data)

    Con's for I2S:
    • When executed in SW, it can be pretty code intensive (probably needs to be done in mostly PASM to support the fastest speeds like 192kHz @ 24-bits)
    • Takes at least 3-pins to make the interface work the right way (you can get away with only the Bit-Clock, L/R-Clock, and Data-line if you don't intend to do sample rate conversion)



    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 yeah.gif[noparse][[/noparse]/joking]

    Post Edited (GreyBox Tim) : 11/22/2008 6:26:08 AM GMT
    601 x 768 - 445K
  • Timothy D. SwieterTimothy D. Swieter Posts: 1,613
    edited 2008-11-19 12:04
    Hey.....I want a TEX Squishy!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Timothy D. Swieter, E.I.
    www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
    www.tdswieter.com
  • Beau SchwabeBeau Schwabe Posts: 6,562
    edited 2008-11-19 17:14
    VIRAND,

    "THX: This is all there is to it!" - You forgot the plug-in COWS - smilewinkgrin.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Beau Schwabe

    IC Layout Engineer
    Parallax, Inc.
Sign In or Register to comment.