Very ambigious and optimistic idea, unlikely to work ;) (aka wireless headset)

[DexterLB]

Please don't say "this is far too complicated, go play outside" and stuff like that... really...

I believe I have 20% of the experience needed for the project (some level of c++ programming, having made lots of PCBs, analogue and digital). The most probable outcome is quitting, but still it's worth the try...

Now, the point:
I want to make a wireless headset (2 channels + stereo microphone, e.g. 2-way stereo.)
I want it to be as digital as it can.

What I propose:
An ARM processor with linux for ARM and connection to WiFi. It should be one of the ARM processors that work with the several linux for ARM distros. I still couldn't find how the sound framework is implemented in the ARM linux kernel... if there really is such support...
for WiFi I'd like to use a Wireless to Ethernet module and use the ethernet input of the ARM, as some models have one.

The high-level protocol idea:
The device captures a preconfigured PulseAudio RDP stream from a PC on the network and plays it while sending a similar RDP stream from it's microphones, preferably by pulseaudio installed in the linux. Then the PC receives this stream and uses it as a virtual stream, type "Input", with the ease of configuration of PulseAudio

I am still searching for a suitable low-cost ARM, if you know one please say...

 

[RadioRon]

Wireless battery operated devices often avoid using 802.11 protocols, like Wifi, because they are somewhat power hungry and will eat your batteries. Have you considered Bluetooth? It is better at battery conservation.

 

[DexterLB]

Wireless battery operated devices often avoid using 802.11 protocols, like Wifi, because they are somewhat power hungry and will eat your batteries. Have you considered Bluetooth? It is better at battery conservation.

Yes but how am I going to transmit the data with bluetooth from the PC? Soundcards with digital outputs are still toooooooooooooooooooooooooooooooooo expensive...

 

[Blueteeth]

Dexter,

If you can't afford a soundcard with digital (S/PDIF) in/out (they go for around $15 US), then you're going to struggle with the financial side of this project. Unless you hack a wifi card, its going to cost a LOT to get 802.11x in your headset. I've seen modules designed for interfacing to microcontrollers priced at about $60 US minimum. Using digital (SP/DIF) is by far the easiest and cheapest way of getting 'digital audio' to and from your soundcard. You could get away with using nordics NRF24Z1, although that is for high quality, and 'one way' communication. Perhaps two seperate circuits using texas instruments USB codecs, using the digital in/out along with the nordic devices.

Also note 802.11x may have high bandwidth, but the encoding/decoding side will cause significant latency. This is fine if you're just playing music form your PC to your headset, as you only have one 'sound source'. But for a microphone? you're producing the sound source, and in skype/gaming, when you talk, the latency is doubled between you talking, and someone responding. Anything over 150ms will start to annoy you.

Bluetooth 2.0 (and 1.2 I believe) has a protocol set up specifically for wireless headsets, although you'll strugggle to get stereo out.

Although Arm micro's are cheap, they are over kill for what you need. Wireless audio, either requires high bandwidth and low latency for 'uncoded' pure audio. Or....it requires a processor with the required hardware for audio encoding 'on the fly' (ADPCM).

If order for you to get some idea's together you will need to work out the following:

- Quality: Is your microphone just used for voice? if so, you could get away with having lower quality, no-one needs CD-quality audio for skype. From this you can decide audio resolution and sample rate. 16bit @ 48kHz is probably your maximum. Although 12 bit is generally fine for mosty applications where you don't need high end audio.

- Range: I'll assume this will be no more than a few metres. Anything more and you'll need lareger antenna's or power amplifiers. This is because, for digital audio, the bandwidth required forces you to use the 2.4Ghz band, which are heavily restricted and so all devices and protocol's have limited power output for a given protocol. (802.11x uses direct sequence spreading, so its power output is less restricted).

- Portablility. Its going to be tough putting all your electornics in a headset, so you'll probably need a seperate box. Plus, batteries take up space and weight so as always, its a balance between battery life and portability.

Radio ron made an excellent point....802.11x use up a lot of power...they were never designed for portable battery powered applications, and they need this power for their direct sequence spreading.

With all things wireless, you're restricted by bandwidth. You mentioned 'two way' radio with stereo speakers and stereo microphone. At CD quality...this would take....16*480000*2 = 1.536MB/sec each way. Thats not including packet over head.

That may sound small given the numbers of todays wireless comms (54mbps in 802.11g) but you must remember, those protocols use burst communication with large packets of data sent in bulk. Audio requires smaller packets to be sent more regularly, which means you're restricted in the size of packet you can send...which makes for inefficient use of radio bandwidth. An example is, the NRF24Z1 may only transmit a maximum of 1.536MB/sec....but its 'over the air' rate is over 4MB/s.

I would start small, even the posibility of analogue, using two seperate reasonable quality radio channels, one for each way. Digital is wonderful, is has the possibility for excellent results, but the initial costs of a digital system,. even low quality, is very high (but increasing quality from the initial setup is very cheap).

Blueteeth

 

[Sceadwian]

Dexter, you need to really explain why you're trying to do what you're suggesting, because everything you've describe screams wrong from so many different perspectives. There are commercial products you could use that would cost less than the shipping on a suitable ARM.

 

[unclejed613]

try packing up the data from the soundcard in a stream, use a USB connected ZigBee card. some of them have enough "horsepower" for the job (250k/S and 500k/S transfer rates), ZigBee uses even less battery power than bluetooth, if the manufacturer's claims are accurate. 802.11 uses a lot of battery power to keep a link active. ZigBee devices can also work in a mesh network, while bluetooth is a star configuration, and 802.11 is also a star configuration. the mesh network is good if you want multiple computers sharing streams with multiple headsets, it doesn't suffer from bottlenecks.

 

[DexterLB]

Dexter,
soundcard with digital (S/PDIF) in/out (they go for around $15 US)

so cheap? Here they cost $80

 

[Sceadwian]

What planet are you from Dexter? Cause on Earth they're much cheaper. =) Try a site like newegg or someplace that won't charge you 500% markup.

 

[DexterLB]

So, these two questions arise: Are there any good S/PDIF decoder ICs? Is CS8414 high-quality enough?

 

[Blueteeth]

So, these two questions arise: Are there any good S/PDIF decoder ICs? Is CS8414 high-quality enough?

Thats a pretty old chip if I remember correctly (I have some samples here from my uni days), although it is high quality, depends what you mean by 'high quality enough'? Enough for what exactly? Have a look at Texas Instruments' website, they have plenty of S/PDIF transmitters/recievers/subsystems. Some recievers use a PLL from the input stream to drive the DAC clock, but this can cause jitter. I'm not sure what you are trying to do with S/PDIF.

 

[Blueteeth]

Btw, its funny you re-animated this thread...I have just started to work on my own wireless headset (stereo headphones with a mic). Its a tough project form a digital point of view, made even worse by only using a single RF link.

One could use a fairly robust proprietary link for high quality digital stereo, and a second one for the microphone, but that costs too much.

I am currently looking at basic high quality/low latency audio compression techniques to squeeze 48khz/16-bit stereo down a 1.5mpbs RF channel, and leave enough room for a microphone and control channel. Even without compression, latency is a very important issue, which is why I warned against 802.11x, since that sends very large packets. If you send a 256 sample package, that has to be buffered both sides, and so your latency is 21us per sample, = 5.3ms. And that is without any form of processing, which would take it up to around 30ms. Altohugh those are just numbers, generally, wifi uses much larger packets, and costs a hell of a lot.

I'm not trying to hijack this thread, just letting you know we're sort of in the same boat.

 

[unclejed613]

there are manufacturers that make audio quality zigbee chips as well. 250kb/s tx/rx should be just fine

 

[Blueteeth]

wow, I didn't know zigbee were planning to go audio....I mean, it makes sense for speech, wireless voip headsets n such, with lower complexity than bluetooth. For CD quality though...unless they add apt-x to it, few codecs would have low enough latency at that quality. Then again....for music, where there is only one source of sound, and non-interactive apps (ie: for listening to music, ipod headsets) it sounds like a winner! Even smaller processors can encode/decode mp3/AAC these days, albeit iwth a total latency approaching 300ms.

For real-time, Bluetooth uses a simplified subband codec, which apparently can run just fine on a small arm7 (perhaps even a dspic, with its MAC hardware). I am still researching that (note: I am out of my depth here).

The only solution I have for 'one-way' audio, is nordics NRF24Z1. No compression, handles all RF and link integrity. Ideal for wireless headsets....my development boards are on their way

 

[DexterLB]

wow, I didn't know zigbee were planning to go audio....I mean, it makes sense for speech, wireless voip headsets n such, with lower complexity than bluetooth. For CD quality though...unless they add apt-x to it, few codecs would have low enough latency at that quality. Then again....for music, where there is only one source of sound, and non-interactive apps (ie: for listening to music, ipod headsets) it sounds like a winner! Even smaller processors can encode/decode mp3/AAC these days, albeit iwth a total latency approaching 300ms.

For real-time, Bluetooth uses a simplified subband codec, which apparently can run just fine on a small arm7 (perhaps even a dspic, with its MAC hardware). I am still researching that (note: I am out of my depth here).

The only solution I have for 'one-way' audio, is nordics NRF24Z1. No compression, handles all RF and link integrity. Ideal for wireless headsets....my development boards are on their way

Wow that's a nice IC! I'll see if I could get my hands on it somehow

 

[Blueteeth]

Yeah, its pretty awesome Before that microlinear (who appear to have dropped off the face of the earth) had a 1.536MB/s transciever, which a company called 'Xinc' (I tihnk) coupled with a DSP to make a 'CD quality bidirecitonal link'. Which would work nicely for a wireless headset (headphones AND a mic).

Using the nordic chip would satisfy the receiving part, but I guess we'll need second link for the microphone...which jstu complicates matters,since the nordic chip handles its frequency hopping internally,so we can't sync two transceievers to 'avoid' eachother. But yes, for wireless headphones, its a winner and I think its used by senheisser in some of their non-bluetooth headphones.