4 channels of audio or control over one bus(in-sync version)

[selvmarcus]

Building block for transmitting 4 channels of audio or control over one busline (or any audio connection) by using a selvmade multiplexer / demultixer.
The sampling rate is therefore effectivly reduced to 24 kHz. This means any frequency contents above 12 kHz is lost. (Think: Old tape recorder)

The 4 oscillators in the demo can be replaced by any audio source. When using the circuit for control signals with low frequency bandwith, like slow
LFOs or EGs, the antil-aliasing lowpass-filters at the input may be omitted (experiment!).

For keeping sender and receiver in sync, some special effort was taken for they are to be put in different slots / voice / DSP areas, which may
start with some delay to each other. As a result, the output of the output audio is muted for a very short period at each patch / variation activation
(not audible).

The resulting audio will still carry some of the inaudible 48 kHz clock. If there should be any problems with that, you can try to add a 6dB
lowpass-filtering at 21kHz (module not shown here) at output.

In the demo, 2 of the 4 oscillators are activated, giving output to left and right stereo channels. Switch the other on and play with them around for proof .

3 voices are also activated, so you can hear a slight change in sound for each patch activation /variation change due to the individual delay of each
of the voices activation. But still, the oscillators (the basic pitch) keep being aligned left / right where they have been, which proofs the inter-area syncing is actually working.


How it works:

The transmitted audiosignal carries the 4 channels by switching between them for each sample.

In the Sender Block, there are two multiplexer stages cascaded, bringing 4 to 2 and then the 2 to 1 channel.

The topmost two valswitch modules are the primary input stage of the multiplexer.
Each is sampling 2 channels of input for every phase of a 24 kHz clock, generated by the clock divider made out of a flip-flop (a little cheaper then the builtin mod).
This clock is derived from an NOR gate with feedback to one of its inputs generating the main 48 kHz clock signal.
The next valswitch samples the previous stage with that fast clock, alternating between the top 2 valswitches outputs for every audiocycle.

The result is then put onto Bus1.

At receivers end (FX-area for the demo), 4 sample-and-hold / track-and-hold modules are used, driven by a combination of the slow
and fast receivers clocks, to select a sample for each channel in turn and also fill up the gaps while the other channels are served.

At patch / variation activation, a one sample click of maximum value (4*64 units) is transmitted over the connection.
This is checked at receivers end with a compare and the clocks are restarted in case.

This event also triggers an EG and mutes the ouput for some miliseconds.


Further notes:

It would be possible to mix resolutions. You could have one channel with 48 kHz, one with 24 kHz and two with 12 kHz (see the 8 channels version
following soon...) over the same connection.


So... what do you want next?
----
Marcus

[editor's note: removed unwanted attachment a per message below. --mosc]

[selvmarcus]

Sorry, mixed up the patches!

Don´t know how to update it above.

Another try....




----
Marcus

---

4audio1bus_sync.pch2
Description:	Building block for transmitting 4 channels of audio or control (12 kHz bandwith each) over one busline by using multiplexing	Download
Filename:	4audio1bus_sync.pch2
Filesize:	2.29 KB
Downloaded:	1179 Time(s)

---

[selvmarcus]

...and thanks to 3phase for the coloring mod

---
Marcus

[blue hell]

And, silly me, I was just about to write "order in the chaos, finally. Thank you for posting this" ...

You can replace attachements but it looks all a bit messy indeed, it's not so hard though to remove the 1st one.

Still thanks tho

[selvmarcus]

Small changes and also building blocks for the 2 channels mux/demux over one bus (with 48 kHz samplerate /
24 kHz bandwith each) added.

I noticed that a clipping level occuring for some reason on the busline used for the sync click would drive the old
patch out of sync, so I used the sync-in block also for the receiver in the FX-area, where I had used the direct logic signal before.

Now it should just re-sync in this case.


You get building blocks for

- Sync Out, kicking Bus1 on startup, needed once per system in a FX-area
- Sync In / Clock, needed for each slot and area
- 4 Channel Sender, with anti-aliasing filters and clock divider, on Bus1
- 4 Channel Receiver, from Bus1, with clock divider and click-muting EG
- 2 Channel Sender, sending to Bus2
- 2 Channel Receiver, from Bus2, with its own slightly cheaper clock

You would of course only need one 48 kHz and one 24 kHz clock (for the 4 channels thing) per area with multiple senders
or receivers. In the demo here, they are duplicated for each block (I hope it´s not adding too much confusion).
Also the bus in/out modules could be reused then, of course.



Patch muted in the toolbar per default.

Feel free for any comments / questions / suggestions, also if you would like more (or less?) documentation.


---------
Marcus

---

4+2audio2bus_snc.pch2
Description:	Building blocks for 4 channel multiplexing of audio or control over one bus with inter-area sync (update). 2 channels version (new) added.	Download
Filename:	4+2audio2bus_snc.pch2
Filesize:	2.8 KB
Downloaded:	1121 Time(s)

---

[3phase]

It seems that this trick is not working on heavier patches...
I had issues where it wasnt possible to get the connection stable from VA to FX

http://electro-music.com/forum/post-72331.html#72331

I initially had the PolyQuenzer patch done with a multiplexed bus..but now i used all 4 fx busses instead...

It would be good to find out if the desired functionality can reached with the actual os or if we need to ask clavia for an optimisation of the os to allow to multiplex the busses. It would be necessary to tell them exactly wher the problem is. I only can say that in such a heavy patch as the polyquencer sync dont gets established..


Another thing...
If syncing needs a signal it would be good if this would work from VA to FX area because the unidirectonal fx busses.

[selvmarcus]

Hi!

I thought about mentioning this earlier...

The trick depends on the Voice Areas to be already activated when the click gets send from FX Area over a bus to them.
This was true in my tests, but may not be the case in heavy patches.

Here I insert a short delay between the variation active signal and the click-forming flip-flop in the sync-sending block.
0.5 ms should be enough, if not, try higher.

You could now put this block anywhere, just make sure it´s only activated once per performance.

Besides this, I had two introduce two extra valswitches in the 4-channel receiver. Seems to me that logic modules at audiorate are
not really in time (exact at the sample) in all cases.

Now I switch the highspeed clock (two different phases) with the lowspeed clock and feed this to the sample&hold for each channel.

------
Marcus

---

4+2audio2bus_ok.pch2
Description:		Download
Filename:	4+2audio2bus_ok.pch2
Filesize:	2.92 KB
Downloaded:	1095 Time(s)

---

[mosc]

[blue hell]

[selvmarcus]

Well, not much, I have to admit.
I just looked at the patch activation signal with my scope tool,
triggering it from the VA, signal came from FX, and it was a few
audiocycles late. So I guessed it fires up voices first, then FX, which
might make some sense. But not sure, could just init all areas and fire up
async, so heavy patch-loaded areas come up later.

I read, the allocation is especially well done, according to Rob in
an article at the time the G2 was presented. Just found it.

Didn´t think of it, yet.

But nevertheless...

4 Motorola 56k at 150MHz.

So roughly 1500 instruction cycles per audiocycle per DSP
or 750 per area maximum.

A minimal modul like the MIX1-1A takes approx. 0.36 % DSP
at audiorate (calculated from 10 modules).

So about 600 of them would fit into one DSP (300 FX + 300 VA).

This means maximal two DSP instruction-cycles for this module, as the
rest 300 had be used for housekeeping, midi processing and so on.
The thing is compiling, because subroutines or jumps are a real waste
here. So one long thread of operations. To allow free routing, all
ouput of a module seems to be written uniformly to zero page locations.
Threads for audio and control processing are different.
(Audio is called 4 times more often than control, of course).

With the DSP, you can do the logic or arithmetic ( like the basic
DSP operation accu=accu+data1*data2) and the data moving interleaved.
Access to anything other than registers or zero-page mem hurts much in
processing time, though.

The simple stereo mixer takes about 0.66 % DSP and about 1.55 % MEM.

The MIX2-1A takes 0.44 % DSP at audiorate. Looks like the granularity
is 0.11 here% ?? I don´t get it yet.

The MIX4-1A takes 0.51%. ? again

I get...about 112 ouputs per area? Figure was lower in article.

Prob 256 locations in zero-page on one DSP (I don´t remember for sure).


Will think about it later.
Only one more note: Inter-DSP audio transmission
is limited, and so moving a lot voices FX-outputs around could be a
problem. Maybe this can be used to guess the allocation used.
Have to look into a hardware manual...


What is fascinating you about the allocation, btw?

/Marcus

[blue hell]

[selvmarcus]

Idea!

Still realtime, but with some latency we could maybe evaluate.
I found some good Motorola DSP 56k docs online:

http://www.soundart-hot.com/english/developers/techdocs.shtml

Also interesting product, it´s a pity they won´t do a MKII.

I think now the serial channel (at least one of the two available) on
a DSP is glued to a specific codec, specific audio in/out.
It´s very straigtforward decision to do it that way.

But there is also the 8bit Host Interface with DMA-channels
and so on for moving audio between DSPs.

Maybe the FX-areas are also glued to a specific DSP, VAs moving around
when unused DSP-power in one slot is used for a voice in other slot.

So we get a path from audio-in at one DSP to another DSP for VA to another DSP for FX and audio-out.
And each DSP has also to carry all 4 aux busses in&out.

1 + 1 + 4 + 4

That is 10*96k*24 bit/s or about 24Mbit/s or 3Mbyte/s.

Much too much for serial round robin connection, looks like HI.


/Marcus

[blue hell]

[selvmarcus]

Sorry, HI = Host Interface.

Chameleon, they sold at least 300, I read somewhere.
And looks like they still doing it, but won´t do another model now.

I am thinking about getting one, or something in that price range
for open DSP development, ah, if just clavia...

/Marcus

[jksuperstar]

OT -- For open DSP development, you might also look at the kX Project...a free driver that takes control of the E-mu 10k1 and 10k2 line of Audio DSPs. It comes with it's own compiler to boot! And the chips can be found in most SoundBlaster, Emu, and Audigy products, so they are practically free.

Back to the Topic - I think the Audio I/O is all handled by the master CPU (IIRC-a coldfire), not the motorola DSPs. I do beleive the DSPs talk to each other via the 8 bit bus also. However, the master CPU I think talks via the serial lines (midi control, etc). It's been over a year since I checked it all out, and now my imagination of what could be has clouded what is. I can look again if there's interest.

[selvmarcus]

OT - what about a new thread: G2 hard+software internals?

Well, I´m familiar with programming the Motorolas, even it´s ten years, I might come back if I feel the need
(If, like, clavia won´t fix the delays ).

And for the Audio I/O you need 4 full-duplex serials with (strange) 24bit,
or is it just 16bit here?
I dunno about the Coldfire... but the DSPs are very well equipped here...
and you don´t have to fiddle with 96kHz on the "slow" control processor then... just what I was thinking.
Would be interesting to know.

All the best,
/Marcus

[jksuperstar]

I agree, a seperate thread for internals is a good idea.