Searching \ for 'digital audio again (less vague)' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/audio.htm?key=audio
Search entire site for: 'digital audio again (less vague)'.

Truncated match.
PICList Thread
'digital audio again (less vague)'
1999\06\28@110527 by John Perkinton

flavicon
face
I design public adress systems, and multizone music systems for a company in
dundee in scotland, which are installed in a large number of sports clubs
thoughout the uk. My current system gives sixteem channels of different
music which is selectable from a wall mounted face plate with lcd display to
let you know what channel you are listening to. The system is card based, so
can be expanded easily for both inputs and outputs, with an input card
having 4 inputs which can take anything from mic level up to speaker level
inputs, and the ouput cards having line-outs, and headphone jecks on the
wall mounted face plates. The unit thansmits its audio over cat5 cable along
with power. Each output has a selectable paging zone out of 24, and you can
have up to 20 outputs on each zone. There is a 24 zone paging console, also
connected via cat 5, with push button zone selection, and each output port
has both 12V and 24V restoration if required. Volume is automatically
increased when a zone is paged. When changing the channel you've selected
the volume is ramped down then up to avoid nasty switching between channels.
The main unit is housed in a 4U rack mounting case which contains the
motherboard, containing the mic input, a firemans mic input for evacuation
purposes, and a voice recording chip for fire purposes. This also has all
the paging logic and has 14 card slots for input and output cards.
The whole unit runs off of pic16c84 4Mhz chips. One for each output. One for
the mic console. One for the motherboard. One for each channel/volume
selector, and is powered from a standard PC power supply. I also have a
fully encased version of the channel/volume selector so that they can be
mounted on sports equipment, so people can listen to television
cahnnels/music/radio whilst excersising, with several TV's on walls so they
can listen to which ever channel they want, but in most rooms the outputs
are taken to 100V line amplifiers and are distributed through ceiling
speakers.

For some reason, even though the audio quality is unsurpassable through the
existing system, my boss wants me to design a digital audio version. This is
going to be a nightmare, he wants 32 stereo channels, down one pair of
cables. Everyone says its impossible including a few of my friends who work
for Philips, but cable TV does it using Nicam so why can't I.

Any ideas, or should I just look for another job, as I only get paid £17,000
a year, and end up working about 75 hours a week with little or no holidays,
no paid overtime. If you have any ideas please don't hesitate to contact me.

Please also let me know of any projects you have done, and I'll let you know
some other mad things I've done with PIC's.

John Perkinton.

1999\06\28@224908 by Stuart O'Reilly

flavicon
face
I've built something similar, it takes in 10 stereo audio signals and it can
distribute it through 8 different outputs. It's controlled of a pic16c73 via an
RS485 network. I've built this for home and am buiding a similar matrix switcher
for video, slowly building up my home automation system.
Regards
Stuart

John Perkinton wrote:

{Quote hidden}

1999\06\28@230619 by Dennis Plunkett

flavicon
face
At 12:55 29/06/99 +1000, you wrote:
>I've built something similar, it takes in 10 stereo audio signals and it can
>distribute it through 8 different outputs. It's controlled of a pic16c73
via an
>RS485 network. I've built this for home and am buiding a similar matrix
switcher
>for video, slowly building up my home automation system.
>Regards
>Stuart
>
>John Perkinton wrote:
>
>> I design public adress systems, and multizone music systems for a
company in
>> dundee in scotland, which are installed in a large number of sports clubs
>> thoughout the uk. My current system gives sixteem channels of different
>> music which is selectable from a wall mounted face plate with lcd
display to
>> let you know what channel you are listening to. The system is card
based, so
>> can be expanded easily for both inputs and outputs, with an input card
>> having 4 inputs which can take anything from mic level up to speaker level
>> inputs, and the ouput cards having line-outs, and headphone jecks on the
>> wall mounted face plates. The unit thansmits its audio over cat5 cable
along
>> with power. Each output has a selectable paging zone out of 24, and you can
>> have up to 20 outputs on each zone. There is a 24 zone paging console, also
>> connected via cat 5, with push button zone selection, and each output port
>> has both 12V and 24V restoration if required. Volume is automatically
>> increased when a zone is paged. When changing the channel you've selected
>> the volume is ramped down then up to avoid nasty switching between
channels.
>> The main unit is housed in a 4U rack mounting case which contains the
>> motherboard, containing the mic input, a firemans mic input for evacuation
>> purposes, and a voice recording chip for fire purposes. This also has all
>> the paging logic and has 14 card slots for input and output cards.
>> The whole unit runs off of pic16c84 4Mhz chips. One for each output. One
for
{Quote hidden}

This is
>> going to be a nightmare, he wants 32 stereo channels, down one pair of
>> cables. Everyone says its impossible including a few of my friends who work
>> for Philips, but cable TV does it using Nicam so why can't I.
>>
>> Any ideas, or should I just look for another job, as I only get paid
£17,000
>> a year, and end up working about 75 hours a week with little or no
holidays,
>> no paid overtime. If you have any ideas please don't hesitate to contact
me.
>>
>> Please also let me know of any projects you have done, and I'll let you
know
>> some other mad things I've done with PIC's.
>>
>> John Perkinton.
>
>


Of course this can be done with Time Division Multiple Access TDMA. It is
the basic building block for telecomunications called E1 and in the States
T1 links, containing 30 VF channels, with each channel using 8kHz of
channel space (Less channels in the States).
In your case unless you can use an exitsting protocol that provides you
with a framing controller, alignment of the frames will not be an easy
matter. You could look at using something like a Mitel ST-bus running at
8.192MHz, as this will give you 120 telephone channels or 30 Stereo
channels with 8kHz bandwidth, or 15 with 16kHz, and all the controll
channels that you need. Of course you will have to do all the
reconstrcution filtering and that soft of stuff for the CODECS (Not as easy
as it sounds)
There are countless numbers of other possible formats (Car CD stacker etc)
ISDN and the like. Be warned this is a big task and to do it on 17000 per
year...

Dennis

1999\06\28@231656 by l.allen

picon face
{Quote hidden}

Yes... I know the type of Boss you have, I used to have one like
that. His best trick was the discuss the project, If I said it was
feasible he would then sell the gear before I had even designed it
and tell me I had 2 months to installation or else.
I quit, got my life back and spent the next 8 months travelling the
globe, and came back and got a real job.

Technically... The bit stream would probably need fibre optics, an
awful lot of bits per second but there are I.C.s that make this
achievable.
Forget R.F. modulation and mixing... the filtering at
generation is very hard, we ended up using cavity filters, diplexers
and other horrible and expensive items to get the signals all
behaving together and that was only four frequencies.


Lance Allen

1999\06\29@093437 by Adam Davis

flavicon
face
Well, maybe I'm babbling here, but let's go ahead and design our own system for
the thrill of it...

Assuming you want cd quality stereo sound and 32 channels running simultaneously
on one twisted pair, then you need:

14400 samples per second, 16 bits per sample, and 64 channels (32 stereo
channels).  So you need to be able to move 14,745,600 bits of data through the
cable.  Now, it is audio, and you really don't need to have it exact, so let's
say that about 100 times a second you send a break which lasts for one chunk(16
bits) which will give you only 14300 samples per second, but won't be audibly
noticable.  Then you'll be able to synchronize the receivers.  Add the overhead
of a start bit and a stop bit (for every 16 bits), and you end up needing to
send 16.6Mbps through a twisted pair.  All you need on the receiver end is a
chip which counts chunks (can't call it a byte, it's a 16 bit chunk) and puts
every 32nd chunk on alternating ADCs.

I haven't read up on rs-485 recently, but I doubt you'll be able to reliably use
a run of the mill rs-485 transceiver for it.  You may even want to look at an
ethernet driver.  At any rate, this entire system depends on a constant supply
of data from the transmitter at a constant speed.  No need to deal with
'assembling' packets of data or buffering anything.  It's more of a multiplexing
system than anything.

-Adam

John Perkinton wrote:
{Quote hidden}

1999\06\29@095936 by Michael Rigby-Jones

flavicon
face
Last time I looked CD quality was 44.1 kHz.

44100 * 16 * 64 = 45.2 MBits/second.  Standard ethernet only goes to
10Mbits/second, although the newer standard is 100 MBits.

Of course you could use compression to cut down the bandwidth.  MP3 gives
pretty good results at only 128kBits/second.  To be honest if this is run of
the mill public address sounds then you could probably get away with a MUCH
lower bandwidth.  I've never heard in-store music that could be described as
hi-fi. I always thought they used a couple of old baked bean tins and a
piece of string :o)

Without wishing to be involved in politics, 17K is a pretty crappy wage if
you are expected to work with this kind of thing.  Especially with those
hours.

> {Original Message removed}

1999\06\30@050850 by John Perkinton

flavicon
face
Does anyone have any mp3 encoding algorithms for dsp's which can encode real
time?
If so you idea is great.

> Um wouldn't it be easier to simply MP3 the audio in question and pass
that.
> 128kbits/sec x 32 channels = 2048kbits/second. rs-485 can handle that
> easily.
>
> BAJ
>

1999\06\30@064354 by Byron A Jeff

face picon face
> >Um wouldn't it be easier to simply MP3 the audio in question and pass that.
> >128kbits/sec x 32 channels = 2048kbits/second. rs-485 can handle that
> >easily.
> >
> >BAJ
> >
> >
>
> Perhaps my calculator is bung, but I get 4.096MB/sec
>

Your calculator is fine. I did the computation in my head and lost a bit.
128 = 7 bits, 32 = 5 bits, total = 12 bits, 1024 = 10 bits, 2 bits left over
(this was my mistake, I thought there was one bit left over), 2 bits is 4,
so 4 x 1024 -> 4096. And that's megabits (Mb) not megabytes (MB) BTW.

And for short runs like in a restaurant, RS 485 can handle it easily. The
real question is what do you need to separate and decode the individual
channels...

BAJ

1999\06\30@064810 by Byron A Jeff

face picon face
>
> Does anyone have any mp3 encoding algorithms for dsp's which can encode real
> time?
> If so you idea is great.

I've lost the original problem in this discussion. I had the impressions,
hopefully not mistaken, that the outgoing stuff to the stations was canned.
This means that you could pre-compute the MP3. If not then you're right and
this becomes a challenge.

If you need to do PA stuff in real time, maybe you could sample that at
64/128 kbits without encoding, pass it in the same channel space as the
compressed stuff, and play it back without having to convert.

How about another copy of the specifications of the problem so that we
can properly evaluate these options?

BAJ
>
> > Um wouldn't it be easier to simply MP3 the audio in question and pass
> that.
> > 128kbits/sec x 32 channels = 4096kbits/second. rs-485 can handle that
> > easily.
> >
> > BAJ
> >
>


'digital audio again (less vague)'
1999\07\01@222217 by Thomas Brandon
flavicon
picon face
You'd need a pretty good DSP to handle MP3 encoding (and a fairly serious
encoding algorithm). To give you an idea, most docs will say you need at
least a 486 just to DECODE MP3. On my P2-300 128MB with the Xing MPEG engine
(about the fastest fair quality (Fraunhoffer's still better) of Audio
Catalyst 2 I get about 4x ripping off a CD.

However there are chips around that should do the job. The only problem is
whether or not you can pump 32 channels into less than 32 CODECs. I'd
imagine it'd be possible with an audio stream like PCM with fixed size
blocks and so on. However, MPEG uses a different kind of data stream (don't
know technical details just knows it's different so it might not matter).

One thing you mightr want to look at it USB. I have no idea on how difficult
it is to implement a host USB device (you could use a PC easily) but other
than that it has a few notable advantages:
       - There are specs for digital audio (including multiple data formats
like PCM, MPEG etc...)
       - If you get USB capable hardware it'll do all the work of handling
multiple data streams including bandwidth allocation/balancing
       - You can plug it straight into a PC
       - According to some it is the next standard for Digital Audio
distribution (both in PC's and other music devices)

USB supports 2 device speeds (the device advertises it's speed): 1.5Mb/s and
12Mb/s. I would suggest 128kbit/s isn't quite high enough for CD quality. I
used to use 160kit/s but now use Variable Bit Rate. I would say VBR is the
way to go (no idea on hardware VBR encoders). In VBR the data rate is varied
to give the best compression rate for each frame (i.e. a frame with little
information will be coded at low bandwidth) thus maximising bandwidth.
For 32 channel at 160kbit/s each:
   160kbit/s x 32 = 5120kbit/s ~5Mb/s

Thus 32 channels of 160k MP3 encoded data should easily fit over a single
USB line.

VBR could increase the quality of the transmitted lines. For instance Audio
Catalyst supports VBR of various quality. At medium quality the data rate
maxes out at about 256k and size is slightly smaller or equivalent to a 160k
normal file. At high quality the data rates peaks at 320k (highest rate) and
the size is about 10% larger than a 160k file. Both these value's are for
Psychedelic Trance songs which are generally fairly 'busy' and so shouldn't
give exceptional results under VBR in terms of size.

The other thing USB allows is the use of different quality streams and thus
better use of bandwidth. For instance the fire microphone can run at a very
low bandwidth as it is speech only. Thus you save bandwidth and minimize
storage space for recording. Obviously if you use VBR this should be
unnecesaary.

For more information on MP3 de/coding check out:
http://www.spectsoft.com/mp3tech/
http://www.angelfire.com/pa2/mpx/

For info on USB standards check out:
http://www.usb.org/

Phillips makes an I2C compatible USB interface but I2C is only 1Mbits. They
also have a chip that does digital and analog audio to USB at up to 24bit
55kHz.

Intel have a USB capable MCS251 compatible MCU and an application note on
connecting it to an audio codec.

Thomas Brandon.

----- Original Message -----
> Does anyone have any mp3 encoding algorithms for dsp's which can encode
real
> time?
> If so you idea is great.
>
> > Um wouldn't it be easier to simply MP3 the audio in question and pass
> that.
> > 128kbits/sec x 32 channels = 2048kbits/second. rs-485 can handle that
> > easily.

1999\07\13@053340 by Nigel Orr

flavicon
face
At 09:32 29/06/99 -0400, you wrote:
>Well, maybe I'm babbling here

You could call it that...

>14400 samples per second, 16 bits per sample, and 64 channels (32 stereo
>channels).  So you need to be able to move 14,745,600 bits of data through
the
>cable.

Try 44100 samples per second, 16 bits, 64 channels, 45MB/s, say 50MB/s as
an absolute bare bones minimum assuming very low packeting, error
correction or whatever overheads...

A realistic system would probably look at at least 100MB/s, with suitable
error detection/correction coding, data packetizing etc etc.

As I've suggested to John in a private email, it's similar to 100BaseT, so
Ethernet cards might be usable to handle the bulk of the work.  Cable
length limits might be a problem, and one pair of cat-5 wouldn't be enough
(one cable to each point would).  It would probably need a PC at each
station to handle the processing and run the Ethernet card, but might be
PICable (valiantly trying to keep it on topic!)

>  Now, it is audio, and you really don't need to have it exact, so let's
>say that about 100 times a second you send a break which lasts for one
>chunk(16
>bits) which will give you only 14300 samples per second, but won't be audibly
>noticable.

I hope you're joking.  If you have a 100Hz break in the signal, that will
be _very_ noticeable.  If you just mean buffer the data and reduce the
sample rate, your already poor bandwidth has just dropped to about 7kHz,
similar to a tape machine in urgent need of repair- I hope that't not where
John is aiming the product (though from some of the machines from sports
clubs in the UK which I have repaired, there may be a case for it!)

>  Then you'll be able to synchronize the receivers.  Add the overhead
>of a start bit and a stop bit (for every 16 bits), and you end up needing to
>send 16.6Mbps through a twisted pair.  All you need on the receiver end is a
>chip which counts chunks (can't call it a byte, it's a 16 bit chunk) and puts
>every 32nd chunk on alternating ADCs.

Synchronization? Error correction?  Control data?  Any of this mean
anything to you?  If you are doing this for home use, it might be
acceptable to have the occasional 'bzzt' or signal going to the wrong room,
but it could ruin a company if its product did that.

>I haven't read up on rs-485 recently, but I doubt you'll be able to
reliably use
>a run of the mill rs-485 transceiver for it.  You may even want to look at an
>ethernet driver.

A good suggestion- I've not seen any RS-485 systems that will run at 100Mb/s

>  At any rate, this entire system depends on a constant supply
>of data from the transmitter at a constant speed.  No need to deal with
>'assembling' packets of data or buffering anything.  It's more of a
>multiplexing system than anything.

It's more of a horrible system than anything- no protocols, no error
detection/correction etc etc etc.

One usable approach would be to use MP3 or similar to compress the data-
say 128kByte per second per stereo channel, for a generally well-accepted
audio quality.  That would reduce the link speed a little (about 60%), and
might make 100BaseT more reasonable to use with less chance of glitches.

With current technology, I'd be _very_ wary of using such a system in a
real PA system... sorry to be so negative, but the numbers just don't add
up unless you're talking about investing in equipment used only in the
upper levels of telecoms- probably far far outside sports club budgets.

Nigel
--
Nigel Orr                  Research Associate   O   ______
       Underwater Acoustics Group,              o / o    \_/(
Dept of Electrical and Electronic Engineering     (_   <   _ (
    University of Newcastle Upon Tyne             \______/ \(

1999\07\13@054208 by Nigel Orr

flavicon
face
At 09:32 29/06/99 -0400, you wrote:
:>Well, maybe I'm babbling here

Ooops, I babbled too!

:One usable approach would be to use MP3 or similar to compress the data-
say :128kByte per second per stereo channel, for a generally well-accepted
audio

That should of course read 128 kbit/second (sorry, just back from 3 weeks
sea trials!), say 256kbit/second with rugged error correction, and a bit of
packeting, 8Mb/s total for 32 stereo channels.  I did think when I was
writing it "that's not much compression", but it didn't quite click ;-(

Now, the only problem would be 32 stereo channels of real time MP3
compression...

The system will still probably be looking at an embedded PC at each outlet,
costing a few hundred pounds, but that may be OK in John's market- if the
music is all pre-stored, disc space is cheap and the compression wouldn't
have to be real-time, but the impression given is that there are live
broadcasts available too...

It _is_ possible, but I don't think it's ready for sports clubs yet...

Nigel
--
Nigel Orr                  Research Associate   O   ______
       Underwater Acoustics Group,              o / o    \_/(
Dept of Electrical and Electronic Engineering     (_   <   _ (
    University of Newcastle Upon Tyne             \______/ \(

1999\07\13@061120 by Michael Rigby-Jones

flavicon
face
> One usable approach would be to use MP3 or similar to compress the data-
> say 128kByte per second per stereo channel, for a generally well-accepted
> audio quality.  That would reduce the link speed a little (about 60%), and
> might make 100BaseT more reasonable to use with less chance of glitches.
>
> With current technology, I'd be _very_ wary of using such a system in a
> real PA system... sorry to be so negative, but the numbers just don't add
> up unless you're talking about investing in equipment used only in the
> upper levels of telecoms- probably far far outside sports club budgets.
>
I think you'll find MP3 works pretty well at 128 kiloBITS/second =
16KBytes/second.  Quite a difference......

32 channels of 16KBytes/s makes only 512Kbytes/second.  10BaseT could handle
this with a huge amount to spare, or RS485 could probably manage it over
short distances.

A cheap fibre optic system would be able to handle over 100 times that data
rate with the bonus of not having to worry about induced interference.  The
real problem as I see it is the decoding and buffering required at the
receiving end would make each node very expensive.  Multiply that by 32 and
the system would not be cheap.

       Regards

       Mike Rigby-Jones

> Nigel
> --
> Nigel Orr                  Research Associate   O   ______
>         Underwater Acoustics Group,              o / o    \_/(
> Dept of Electrical and Electronic Engineering     (_   <   _ (
>      University of Newcastle Upon Tyne             \______/ \(

1999\07\13@074823 by Byron A Jeff

face picon face
-
- > One usable approach would be to use MP3 or similar to compress the data-
- > say 128kByte per second per stereo channel, for a generally well-accepted
- > audio quality.  That would reduce the link speed a little (about 60%), and
- > might make 100BaseT more reasonable to use with less chance of glitches.
- >
- > With current technology, I'd be _very_ wary of using such a system in a
- > real PA system... sorry to be so negative, but the numbers just don't add
- > up unless you're talking about investing in equipment used only in the
- > upper levels of telecoms- probably far far outside sports club budgets.
- >
- I think you'll find MP3 works pretty well at 128 kiloBITS/second =
- 16KBytes/second.  Quite a difference......
-
- 32 channels of 16KBytes/s makes only 512Kbytes/second.  10BaseT could handle
- this with a huge amount to spare, or RS485 could probably manage it over
- short distances.
-
- A cheap fibre optic system would be able to handle over 100 times that data
- rate with the bonus of not having to worry about induced interference.  The
- real problem as I see it is the decoding and buffering required at the
- receiving end would make each node very expensive.  Multiply that by 32 and
- the system would not be cheap.

I think the whole time I was thinking about the chip level solutions that do
MP3 decoding. I'm not sure if such chips require a constant bit stream but
even that could be done with a bit of buffering.

But honestly at today's costs an embedded PC could be deployed at less than
$200 a node. They wouldn't need any disk space, you can find MB with sound
on board. Maybe even ethernet too. Even a K6 166 has no problems decoding
in real time and 32 MB of ram is dirt cheap for buffering. The biggest problem
is form factor.

If you haven't guessed, a PC based MP3 player is on my list of things to do.

BAJ

1999\07\13@093307 by Adam Davis

flavicon
face
You are, of course, correct.  I was trying to indicate how to accomplish such a
system with a PIC, whereas the quality really requires something more involved.
I don't think the PIC would handle this type of work without a lot of kludging,
though I should have said so originally.

And yes, I did mess up the 44100, it's been awhile since I've dealt with audio.
<sigh>  Time moves too quickly...


-Adam

Nigel Orr wrote:
{Quote hidden}

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...