I want to design a system, unless something similar exists, that
multiplexes digital audio signals but also allow for mixing of those
signals in arbitrary ways. This should be relatively cheap because I
want to use a lot of them.

The signal is arranged Sample1_audio1, sample1_audio2, etc...

Where a sample is n bits with some way to determine when a new sample
happens(I guess another line to signal the new bit or a serial like
protocol with start and stop after a "frame").

In any case it should not be difficult to "mix" to signals. I would
just extract a sample, multiply it by a the "mix" value, and add it to
a some a buffer.

But how difficult will this be to implement using discrete components
(IC's but not fpga's or uP's)?  The number of signals is fixed around
20(the more the better). The audio rate is ~200khz @ 24-bit. 200khz is
over sampling so please don't whine about the human ear not being able
to hear above 20khz. This requires about 5Mhz per audio signal.

Once the signal's are mixed the new mixed signal is added to a slot in
the "bus"(it will replace one of the slots as designated by the user).

If this is easily implementable in an fgpa and doing it "discretely"
is just as costly then I suppose it is the better option. I'm just not
quite sure...

"B...@gmail.com" <b...@gmail.com> wrote in message 
news:8...@t21g2000yqi.googlegroups.com...
>I want to design a system, unless something similar exists, that
> multiplexes digital audio signals but also allow for mixing of those
> signals in arbitrary ways. This should be relatively cheap because I
> want to use a lot of them.
>
> The signal is arranged Sample1_audio1, sample1_audio2, etc...
>
> Where a sample is n bits with some way to determine when a new sample
> happens(I guess another line to signal the new bit or a serial like
> protocol with start and stop after a "frame").
>
> In any case it should not be difficult to "mix" to signals. I would
> just extract a sample, multiply it by a the "mix" value, and add it to
> a some a buffer.
>
> But how difficult will this be to implement using discrete components
> (IC's but not fpga's or uP's)?  The number of signals is fixed around
> 20(the more the better). The audio rate is ~200khz @ 24-bit. 200khz is
> over sampling so please don't whine about the human ear not being able
> to hear above 20khz. This requires about 5Mhz per audio signal.
>
> Once the signal's are mixed the new mixed signal is added to a slot in
> the "bus"(it will replace one of the slots as designated by the user).
>
> If this is easily implementable in an fgpa and doing it "discretely"
> is just as costly then I suppose it is the better option. I'm just not
> quite sure...
>
>
>

Something like this. There may be a dsp that will do the job. You do need to 
add a register for each input channel level at each output. If you want 
analog output you need some dacs. You need all of the inputs on each 
processor. The number of outputs on each processor is limited by processing 
speed.A regular processor could also be used but would probably be severely 
limited as to the number of inputs. You could also build a microsequencer to 
run the system.

Bob 

<c...@att.net> wrote in message 
news:pqB1m.3149$v...@flpi145.ffdc.sbc.com...
>
> "B...@gmail.com" <b...@gmail.com> wrote in message 
> news:8...@t21g2000yqi.googlegroups.com...
>>I want to design a system, unless something similar exists, that
>> multiplexes digital audio signals but also allow for mixing of those
>> signals in arbitrary ways. This should be relatively cheap because I
>> want to use a lot of them.
>>
>> The signal is arranged Sample1_audio1, sample1_audio2, etc...
>>
>> Where a sample is n bits with some way to determine when a new sample
>> happens(I guess another line to signal the new bit or a serial like
>> protocol with start and stop after a "frame").
>>
>> In any case it should not be difficult to "mix" to signals. I would
>> just extract a sample, multiply it by a the "mix" value, and add it to
>> a some a buffer.
>>
>> But how difficult will this be to implement using discrete components
>> (IC's but not fpga's or uP's)?  The number of signals is fixed around
>> 20(the more the better). The audio rate is ~200khz @ 24-bit. 200khz is
>> over sampling so please don't whine about the human ear not being able
>> to hear above 20khz. This requires about 5Mhz per audio signal.
>>
>> Once the signal's are mixed the new mixed signal is added to a slot in
>> the "bus"(it will replace one of the slots as designated by the user).
>>
>> If this is easily implementable in an fgpa and doing it "discretely"
>> is just as costly then I suppose it is the better option. I'm just not
>> quite sure...
>>
>>
>>
>
> Something like this. There may be a dsp that will do the job. You do need 
> to add a register for each input channel level at each output. If you want 
> analog output you need some dacs. You need all of the inputs on each 
> processor. The number of outputs on each processor is limited by 
> processing speed.A regular processor could also be used but would probably 
> be severely limited as to the number of inputs. You could also build a 
> microsequencer to run the system.
>
> Bob
>
I guess it would help if I posted the diagram.

c...@att.net/mixer.pdf" target=_blank rel="nofollow">http://geocities.com/c...@att.net/mixer.pdf

Bob

On Jun 27, 1:44=A0pm, "Bob.Jones5...@gmail.com"
<bob.jones5...@gmail.com> wrote:
> I want to design a system, unless something similar exists, that
> multiplexes digital audio signals but also allow for mixing of those
> signals in arbitrary ways. This should be relatively cheap because I
> want to use a lot of them.
>
> The signal is arranged Sample1_audio1, sample1_audio2, etc...

This is the domain of sound programs (like Logic Pro on a Macintosh).
Smaller  numbers of channels are do-able with the nearly-free
software, like GarageBand and iDVD.

> In any case it should not be difficult to "mix" to signals. I would
> just extract a sample, multiply it by a the "mix" value, and add it to
> a some a buffer.
>
> But how difficult will this be to implement using discrete components
> (IC's but not fpga's or uP's)? =A0The number of signals is fixed around
> 20(the more the better). The audio rate is ~200khz @ 24-bit.

Ahh, you don't want to use a standard audio encoding.   If your
samples
are all the same, it's easier than if they aren't, but you WILL  have
to
reinvent the wheel.   It'll be harder if you insist on 'using
discrete'
than if you stick with massproduced computing machinery.

If it were an analog signal, you could buffer all the inputs with
high output impedance gain-controlled amplifiers (LM13700 is
a dual of one such amp), and just connect all the outputs together
(which is allowed because they have high output impedance).
The 'control' function would then just be generating slow waveforms
to program all the gain-control pins, which is relatively easy.

On Sat, 27 Jun 2009 13:44:25 -0700, B...@gmail.com wrote:

> I want to design a system, unless something similar exists, that
> multiplexes digital audio signals but also allow for mixing of those
> signals in arbitrary ways. This should be relatively cheap because I
> want to use a lot of them.
> 
> The signal is arranged Sample1_audio1, sample1_audio2, etc...
> 
> Where a sample is n bits with some way to determine when a new sample
> happens(I guess another line to signal the new bit or a serial like
> protocol with start and stop after a "frame").
> 
> In any case it should not be difficult to "mix" to signals. I would just
> extract a sample, multiply it by a the "mix" value, and add it to a some
> a buffer.
> 
> But how difficult will this be to implement using discrete components
> (IC's but not fpga's or uP's)?  The number of signals is fixed around
> 20(the more the better). The audio rate is ~200khz @ 24-bit. 200khz is
> over sampling so please don't whine about the human ear not being able
> to hear above 20khz. This requires about 5Mhz per audio signal.
> 
> Once the signal's are mixed the new mixed signal is added to a slot in
> the "bus"(it will replace one of the slots as designated by the user).
> 
> If this is easily implementable in an fgpa and doing it "discretely" is
> just as costly then I suppose it is the better option. I'm just not
> quite sure...

Onto what sort of a channel do you wish to multiplex these signals?  
Something like USB, or the now-obsolete IEEE-1394/Firewire, to go from a 
box to a PC?  Something like RocketIO to go from one chip to another on a 
board, or between two closely-spaced boards inside a box?  A 
transcontinental cable?

You're talking about enough logic content that doing it with discretes 
would be huge, troublesome and expensive; depending on the nature of your 
channel and what you _really_ want to accomplish this would be a routine 
to moderately difficult job using FPGAs or DSPs.

-- 
www.wescottdesign.com

On Jun 29, 11:13=A0am, whit3rd <whit...@gmail.com> wrote:
> On Jun 27, 1:44=A0pm, "Bob.Jones5...@gmail.com"
>
> <bob.jones5...@gmail.com> wrote:
> > I want to design a system, unless something similar exists, that
> > multiplexes digital audio signals but also allow for mixing of those
> > signals in arbitrary ways. This should be relatively cheap because I
> > want to use a lot of them.
>
> > The signal is arranged Sample1_audio1, sample1_audio2, etc...
>
> This is the domain of sound programs (like Logic Pro on a Macintosh).
> Smaller =A0numbers of channels are do-able with the nearly-free
> software, like GarageBand and iDVD.
>
> > In any case it should not be difficult to "mix" to signals. I would
> > just extract a sample, multiply it by a the "mix" value, and add it to
> > a some a buffer.
>
> > But how difficult will this be to implement using discrete components
> > (IC's but not fpga's or uP's)? =A0The number of signals is fixed around
> > 20(the more the better). The audio rate is ~200khz @ 24-bit.
>
> Ahh, you don't want to use a standard audio encoding. =A0 If your
> samples
> are all the same, it's easier than if they aren't, but you WILL =A0have
> to
> reinvent the wheel. =A0 It'll be harder if you insist on 'using
> discrete'
> than if you stick with massproduced computing machinery.
>
> If it were an analog signal, you could buffer all the inputs with
> high output impedance gain-controlled amplifiers (LM13700 is
> a dual of one such amp), and just connect all the outputs together
> (which is allowed because they have high output impedance).
> The 'control' function would then just be generating slow waveforms
> to program all the gain-control pins, which is relatively easy.

This is an embedded solution and does not work with a pc or similar
device. Because it is actually a mixture of digital and analog I need
some way to pass around signals easily as I do not want to hardwire
the signal chain.

On Jun 29, 12:12=A0pm, Tim Wescott <t...@seemywebsite.com> wrote:
> On Sat, 27 Jun 2009 13:44:25 -0700, Bob.Jones5...@gmail.com wrote:
> > I want to design a system, unless something similar exists, that
> > multiplexes digital audio signals but also allow for mixing of those
> > signals in arbitrary ways. This should be relatively cheap because I
> > want to use a lot of them.
>
> > The signal is arranged Sample1_audio1, sample1_audio2, etc...
>
> > Where a sample is n bits with some way to determine when a new sample
> > happens(I guess another line to signal the new bit or a serial like
> > protocol with start and stop after a "frame").
>
> > In any case it should not be difficult to "mix" to signals. I would jus=
t
> > extract a sample, multiply it by a the "mix" value, and add it to a som=
e
> > a buffer.
>
> > But how difficult will this be to implement using discrete components
> > (IC's but not fpga's or uP's)? =A0The number of signals is fixed around
> > 20(the more the better). The audio rate is ~200khz @ 24-bit. 200khz is
> > over sampling so please don't whine about the human ear not being able
> > to hear above 20khz. This requires about 5Mhz per audio signal.
>
> > Once the signal's are mixed the new mixed signal is added to a slot in
> > the "bus"(it will replace one of the slots as designated by the user).
>
> > If this is easily implementable in an fgpa and doing it "discretely" is
> > just as costly then I suppose it is the better option. I'm just not
> > quite sure...
>
> Onto what sort of a channel do you wish to multiplex these signals? =A0
> Something like USB, or the now-obsolete IEEE-1394/Firewire, to go from a
> box to a PC? =A0Something like RocketIO to go from one chip to another on=
 a
> board, or between two closely-spaced boards inside a box? =A0A
> transcontinental cable?
>
> You're talking about enough logic content that doing it with discretes
> would be huge, troublesome and expensive; depending on the nature of your
> channel and what you _really_ want to accomplish this would be a routine
> to moderately difficult job using FPGAs or DSPs.
>
> --www.wescottdesign.com

Another method would be to have a central unit that had a buffer where
each memory "slot" would correspond to an audio sample. The unit could
dish out and update the buffer for all the modules. The problem is
that each module would use a dedicated line and most lines would not
be using much of the bandwidth available. The main problem is routing
as it is much easier to have a bus. But since all the audio samples,
given an instant in time, should be available it seems natural to
stick them all on one wire.

I believe I can reduce the complexity by not mixing the signals at
each step but have a "mixer" module. The problem here is that the
number of audio slots needed will probably increase dramatically and
I'll need more than one wire or use a high clock.

B...@gmail.com wrote:

> I want to design a system, unless something similar exists, that
> multiplexes digital audio signals but also allow for mixing of those
> signals in arbitrary ways.

Routing and mixing are two different problems. Routing the TDM signals 
is trivial, mixing is much more complex.

> This should be relatively cheap because I
> want to use a lot of them.

Use a digital audio processor such as TAS3103. It has a bunch of digital 
inputs and outputs. You can route and mix the signals in all kinds of 
combinations. You can also connect several DAPs to multiply the number 
of channels. This is likely to be simpler and cheaper then any DSP or 
FPGA solution.


> But how difficult will this be to implement using discrete components
> (IC's but not fpga's or uP's)?

Completely impractical.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On Wed, 1 Jul 2009 12:36:43 -0700 (PDT), "B...@gmail.com"
<b...@gmail.com> wrote:

>On Jun 29, 11:13=A0am, whit3rd <whit...@gmail.com> wrote:
>> On Jun 27, 1:44=A0pm, "Bob.Jones5...@gmail.com"
>>
>> <bob.jones5...@gmail.com> wrote:
>> > I want to design a system, unless something similar exists, that
>> > multiplexes digital audio signals but also allow for mixing of those
>> > signals in arbitrary ways. This should be relatively cheap because I
>> > want to use a lot of them.
>>
>> > The signal is arranged Sample1_audio1, sample1_audio2, etc...
>>
>> This is the domain of sound programs (like Logic Pro on a Macintosh).
>> Smaller =A0numbers of channels are do-able with the nearly-free
>> software, like GarageBand and iDVD.
>>
>> > In any case it should not be difficult to "mix" to signals. I would
>> > just extract a sample, multiply it by a the "mix" value, and add it =
to
>> > a some a buffer.
>>
>> > But how difficult will this be to implement using discrete =
components
>> > (IC's but not fpga's or uP's)? =A0The number of signals is fixed =
around
>> > 20(the more the better). The audio rate is ~200khz @ 24-bit.
>>
>> Ahh, you don't want to use a standard audio encoding. =A0 If your
>> samples
>> are all the same, it's easier than if they aren't, but you WILL =
=A0have
>> to
>> reinvent the wheel. =A0 It'll be harder if you insist on 'using
>> discrete'
>> than if you stick with massproduced computing machinery.
>>
>> If it were an analog signal, you could buffer all the inputs with
>> high output impedance gain-controlled amplifiers (LM13700 is
>> a dual of one such amp), and just connect all the outputs together
>> (which is allowed because they have high output impedance).
>> The 'control' function would then just be generating slow waveforms
>> to program all the gain-control pins, which is relatively easy.
>
>This is an embedded solution and does not work with a pc or similar
>device. Because it is actually a mixture of digital and analog I need
>some way to pass around signals easily as I do not want to hardwire
>the signal chain.

At which point the method of choice becomes a PC embed.  Something
like PC104.  There is sufficient processing power, USB interface
support (for the digitizers and optional DACs), and a minimal OS and
carefully tuned interface and you are golden.  If you include GPL
portions be careful of the licenses and clearly segregate which is
your stuff and which is GPL.  Commercial OS and SW licenses can kill
you on cost (per unit) instead.