'Remote' audio playing

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Summary for those that don't want to read the waffle:
What chip would you recommend to play audio files connected via a link to a computer? The system will consist of multiple nodes, each connected together, with one or more connected to a computer/media, and all need to get hold of the audio from any other node.


Hi,
(I wasn't sure where to put the thread, as i was thinking of using a 32bit chip. however looking through the forum I notice people have done similar things with the 8bit chips, and since i want to keep it simple (stupid), this looks like a better option (cheaper is also good to). I guess this is the right place then - moan if its not!)

I'm doing a project for my University course (electronic engineering), and am looking for a chip to play audio. I'm in my third year, and have used a few different ATmega's and the Butterfly.

I want something relatively simple to implement since the audio playing isn't a major part of the project. While I'm over halfway through my course its best if you treat me as a complete novice (which I pretty much am).

The system will contain lots of nodes distributed around a building, Several of which will be connected to computers (probably via USB, but perhaps Ethernet or something else). Each node will get requests to play music given by a software program on the connected PCs. This program will basically spit out a track to be played, which then needs to find its way to the required node.

Previously I was looking to pass the file to the required node, but I've realised since having a look round the forum this is probably a stupid idea because it would require on-board decoding. So I'm guessing the best way would be to decode the audio file local with some ready made software and then pass that to the node? (is a midi file a good choice?)

What chip would you recommend for this job? Simple is better, and something with ready made code/hardware would also be good, but at the same time cheap. As mentioned before this isn't the main part of the project so I can cheat by grabbing some ready made code and hardware (having said this, ready made systems are slightly less fun).

Extra processing power isn't a bad thing, as I want to allow for expansion possibilities. My software coding is sketchy, although I have used a large range of languages. I usually code by working from books and examples - can't code fluently in any language.

Thanks for any help!

I've got a website part built to explain the project as I go. once I've finished the website I'll let you know the address and you can see how the project progresses.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I wasn't sure where to put the thread, as i was thinking of using a 32bit chip

As this is the AVR8 forum I'll say that they are quite capable of doing audio even up to 44.1kHz CD quality but if you try to do a "software only" solution then (apart from a few selected AVR8s and the Xmegas) you won't have a DAC so you'd have to use PWM and even running the timer to do this as fast as possible this will limit your audio bandwidth (and resolution to 8 bit).

So you might want to look at connecting a DAC to an AVR8 or do the "poor man's solution" and use an r-2R ladder on 8 port pins to implement one yourself.

With 32 bit the world is more likely you shellfish of choice as they'll have more processing bandwidth and more likelihood of (higher resolution) DACs

All this refers to the audio once you've got it back to plain PCM samples. How you actually pass the data around and decode it is another question. An 8bit 20MHz AVR8 cannot really do much more than ADPCM decode without aid from external silicon. It couldn't, for example, decode MP3 in realtime in software alone. So you might have to pass decoded PCM to the AVR8s but that then puts the onus on your inter-CPU bandwidth and how fast the AVR8 can receive/process it. Again, this would be much easier with 32 bits that could do soft decode of MP3. (anything from about a 50MHz ARM upwards can do this - the more CPU the higher the achievable bit rates)

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd think that it could be tempting to use a tiny AVR on the end of an RS232 cable pushing data at some 230kbps. Probably even "phantom powered" by the RS232 voltage, like an old mouse?

Using 10 bits of the 16-bit timer, that would be 15655 ksps for a 16MHz atmega and 18ksps for a 18.432MHz-clocked mega. That's almost broadcast FM-radio-quality. But at 230kbps you can't deliver enough samples in time. You could then choose to use some different encoding method like u-law, to pack wider dynamic range in fewer bits, or try a higher USART speed. In theory rates go up to 2Mbps, but I doubt you can have really long wires at such speeds.

The Dark Boxes are coming.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Funny you should mention an AT tiny (I assume that's what you mean by a tiny avr?) cause I was looking at them for another part of the project. A guy has done a little bit of genius:
http://micah.navi.cx/2008/09/usi...

Not quite sure what you mean with the tiny. USB uses RS232? so connect a AT tiny to a link directly from the PC and just pass on info ready for playing?

I'll have a look at connecting DAC's to some avrs if I can't find an on board on which would be sufficient. I've added SRAM to a ATmega48 before and seem to remember is pretty simple. Something I'll look into is the speeds at which the ports work which I'll connect the DAC to (as you mentioned). I guess there will be a chip fit for this though.

As for different encoding methods - I'm at a loss here. I have no idea which would work best, and how to do them with the chips. I'm assuming I can grab a function from a lovely bells and whistles library to do the encoding for me, so its just picking the best method.

I was speaking with a house mate the other day, and we were at a bit of a loss between the difference between .wav and midi files. The way I understand it there basically the same thing, but from him I gather that's not right. Above I meant to say wav not midi.
Is a file that's being played decoded into a wav file? that would be a long string of pitch, amplitude etc, which is exactly what I want to pass to the dac to turn into a lovely speaker friendly sound? Feel free to tell me I'm stupid and need to research it myself here.

Over the next few days to week, I'll have a look at some AVRs and see if I can work out for myself what I need, then I'll post here to double check it would work and that there's not a better system.

I've got the interim report in as soon as I get back after the hols so its sucking the life out of me at the moment! once that's out the way its all building and the fun stuff though! (and the less fun from the onslaught of bugs that I attract! :D)

[thanks for the help so far!]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

you could use the nordic nRF24Z1 chips which are an audio transmitter/receiver. You could also use other RF chips from the nordic nRF24 range for data instead which could be better suited but for a simple 10m audio link, you cang get past the nRF24Z1 chip. i havent used it (yet) but it is being designed into a few new projects i am working on

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A .mid file is a recording of MIDI events for a General Midi-compatible synthesizer. They can be played by loading them in media player and routing the stream into a GM-compliant sound module. Some soundcards have hardware synths, Windows has builtin GM-compliant software emulated synth, so does QuickTime and plenty of other third-party software. Midi data, in the most basic form, are sequences of timed key-on/key-off events for one or many instruments.

WAV-file is "just" sampled sound. It can be encoded in many different formats. Programs like Audacity allow every imaginable operation on sampled sound.

The Dark Boxes are coming.