The Kronos Inner Workings - For the brave ones ;-)

roblof · Post by **roblof** » Tue Jul 03, 2012 10:35 pm

Heider wrote:Roblof... I thought you might like this one mate...

I now know why SHARK could not play audio when you connected to Windows-7,... it's because it's BLANK!... it had no samples loaded into it, no mixer-settings, no configuraion to tell it how to redirect the audio or what to do with it.

By pumping some data into it's frame-buffer, it can play it as Audio with some commands!... Similar to "Loading Files..." on the startup screen...

Yes, the loading time can definitely improve to be much (A LOT) faster...

Kind Regards
Heider

Yeah, I came to the conclusion earlier that the McASP needs to be setup to control streams, mixer and a/d + d/a converters.

I don't think shark is as dumb as it looks. I think there are some heavy stuff being executed...

Heider · Post by **Heider** » Tue Jul 03, 2012 10:41 pm

Sorry Roblof,

I think what I meant by dumb device is that it does not do anything unless asked by the MOBO/CPU, which is what I can see on the code.

Yes, there are threads running inside SHARK to process audio signals and come up with the sound-engine using the samples, but, it's dumb in a sense that it does not do decisions unless the MOBO's CPU is behind it.

I hope I explained it better now.

Kind Regards
Heider

1jordyzzz · Post by **1jordyzzz** » Thu Jul 05, 2012 1:21 am

so the mobo's CPU (atom) is not processing the sound?

Heider · Post by **Heider** » Thu Jul 05, 2012 6:52 am

Good morning 1jordyzzz,...

Think of SHARK as a standard Sound-Card with a little thing called VGA stuck out of it's head... That sound card is slightly more customised in terms of taking more configuration profile from MOBO with things like audio and mixer mappings, and some basic wave-sequence-data.

Sound cards in general and I remember going back to the first one I've worked on; Creative Labs SoundBlasterPro with mod-play and voytra, etc, all cards in general works in two ways:

1) Polling mode: This mode would cause the CPU to load the data and stream it byte-by-byte into the sound-card, which makes the sound play, although this is very accurate and can ensure no jurkiness, however it does take a lot of time and power from the main CPU since it's a very fast entity comparing to the very slow I/O.

2) DMA Mode: Although very old now, but this is considered to be the "latest" technology in terms of how to play music, regardless of how you are plugging in your device (USB/PCI/FireWire etc), the device would agree with the CPU on a shared memory-space (on MOBO in this case), whereas the CPU loads a big chunk from the file-system (Linux), and then place it on that shared-memory, once it's done then the CPU would tell the device to go-ahead and start working on it, the device then would take this data read it however it sees fit based on the algorithms setup, and play that audio, once it's done it would then sends an IRQ to the CPU to let it know that (I'm finished, send me more) or (I'm finished, that's it), the CPU in this case would have more time to do other things whilst the device is playing the audio. These are things such as waiting for you to press "STOP" or do something on the screen etc...

SHARK here does polling upong starting up the system (which is why you see the long delay in startup), the CPU is pushing a lot of data into it, once done, it would then switch to DMA-mode (Direct Access Memory mode) as mentioned above.

SHARK is developed by Korg, which is a sound card with a little more customised logic in it, this allows further processing of audio signals, such as more mixing, more configuration changes to the audio before it hits the speaker bus.

SHARK is a dumb device in a sense that it's no more (or just slightly more) than an audio-card with some additional processing in it to play the audio as see fit by MOBO.

Streaming audio directly from a hard disk into the speaker, has to be done by MOBO+SHARK in a sense that MOBO loads a chunk of the sample into a memory, asks SHARK to play it and then SHARK would come back to MOBO asking (OK, this part is played, give me the rest) through an IRQ (i.e. CPU Interrupt Request),... and then MOBO loads another piece into that memory and then off-you-go, this is repeated until the sample from disk is completed, then the sound stops.

One of the reasons why I mentioned earlier that the system is badly-coded, is because of using single-buffers in communications between MOBO and SHARK, this limits the audio and most likely is the reason why changing anything on the system (set-list, combi, etc), forces Korg to stop playing the rhythem, otherwise, if they don't then upon changing an option and the DMA is working on the buffer half the way through then a bang or jurkiness can be heard from the speaker which is very bad from a musical instrument. The solution here is to use double-buffering for such functionality at the cost of losing some other "hardly used" functions so that the rhythem can continue smoothly as the program is changed. It's not a quick implementation, but it does solves the problem.

Other samples (your user-samples) would be stored in the original system memory, and played thorugh the same DMA type.

Polling is used mostly to control SHARK at the time it's playing the audio, and sometimes to add further sound-processing, but very rarely.

I hope this explains it and it's limitation why it's been coded that way, and hopefully if Korg is reading this, then they might give it another thought to come up with something better.

Mind you, if this is to be implemented by them, then it's not a "quick fix", it's a re-implementation of the existing system due to the way it's been coded, not sure if they are willing to do that at this stage for no cost involved, I offered to help, haven't heard anything for the past 2 days yet, which is why I am working on this now anyway hoping to produce something useful to all (including Korg to save them some time)...

Kind Regards
Heider

SeedyLee · Post by **SeedyLee** » Thu Jul 05, 2012 7:57 am

One of the reasons why I mentioned earlier that the system is badly-coded, is because of using single-buffers in communications between MOBO and SHARK, this limits the audio and most likely is the reason why changing anything on the system (set-list, combi, etc), forces Korg to stop playing the rhythem, otherwise, if they don't then upon changing an option and the DMA is working on the buffer half the way through then a bang or jurkiness can be heard from the speaker which is very bad from a musical instrument.

Hi Heider,

If the use of single-buffering was the cause of rhythms not being sustainable through program changes, why does the employment of a single buffer not affect the operation of SST?

Using a single buffer between SHARK and the motherboard surely doesn't preclude utilisation of more complex buffering techniques within software that would handle more complex functions such as SST - in fact, if this was the case, I would imagine that a single hardware buffer would be preferable from a latency and memory efficiency perspective?

My understanding is that using a double-buffering technique for USB transfer would mean that neither buffer could be touched whilst a buffer copy or buffer switch was occurring, potentially introducing latency. There could be a very good performance reasons that a single-buffer was employed.

In other words, it's quite possible that the DMA transfer over USB should not be affected by a change between modes any more than it would be by any other parameter change. This single buffer simply takes data across the USB, whilst complex software buffers ensure that there is a continuous, uninterrupted stream into the single buffer.

Just a thought.

SeedyLee · Post by **SeedyLee** » Thu Jul 05, 2012 8:04 am

Also, it is my understanding that USB only supports host-based polling - DMA is not supported directly over USB, unlike Firewire where DMA between devices is supported (and makes a great vector of attack for obtaining in memory-encryption keys from running systems ...)

Heider · Post by **Heider** » Thu Jul 05, 2012 8:52 am

Hi SeedyLee... (don't know, I keep typing SandyLee whenever I try to reply to you)... do you mind changing your name into SandyLee, so that I can type it in that way

?

.. just kidding...

Now, back to subject...

Ok, I have no idea where you got the impression that a USB has no DMA?!... I have programmed many controllers in particular the PIC_16C745 and PIC_16C745U, the USB definitely supports DMA, in fact any device plugged into the PC going thorugh the North or South bridge (including USB, PCI etc) *does* uses DMA!... So, for that I would urge you to please download an read more about the Intel architecture for North and South bridges, or if you like the simple version, you might like to google "Does USB needs a DMA", see what comes up...

In regards to SST, sadly with the email I received from Korg asking not to disclose how things were coded or exactly done, therefore, I cannot comment "exactly" on how the device work, my explanation regarding SHARK and MOBO starts with: (In general, and taking SoundBlaster as a similar example...) should inicate the idea or the gyst behind it.

Also another statement somewhere in my message saying "If Korg are reading this then they can do..." The idea is there, and the limitation is described very clearly from what I've witnessed, the mixing is done by Shark but the memory is shared on Mobo, that's all I can say since it's general knowledge and done by all sound devices which happens to be same standard.

SeedyLee, I am sure Korg would've wanted this to work (i.e. no limitation on stopping drums when changing audio), but the limit is described there, with "an idea" to fix it, I am currently working on this idea, and will (as usual) surprise everybody with the fix, for that, I need Korg's blessing or support (well, US Support not Mr. S. from the UK this time hopefully)...

I think with the DMA, you might have been confused with "Legacy IRQ support", not DMA, since on "Protected Mode" Intel has moved into APIC as opposed to PIC (0-7 + 80h-87h IRQs).. Hence allowing Legacy USB IRQ support in BIOS or letting the OS do that in PMODE via APIC.

Anyway, I hope this explains the picture without going into too much details on how Korg did it.

Got to go back into my work now, wish I could stay and talk about this more... Have a good day mate...

Kind Regards
Heider

SeedyLee · Post by **SeedyLee** » Thu Jul 05, 2012 10:58 am

Hi Heider,

I will change my name to Sandylee, just for you

It sounds like you got a positive response from Korg in relation to your efforts - or at least certainly a response that hopefully won't impede your work.

I don't think I'm confused about DMA, but I do think we're talking slightly different purposes. My understanding is as follows: whilst the USB controller may be able to utilise DMA to communicate with the North/South Bridge, the USB *protocol* itself doesn't support DMA. That is, all devices on the USB bus have to be polled by the host controller before responding, but this does not typically tie up the processor on each device as the USB Controller for each device will use DMA to transfer data. On the other hand, the IEEE1394 bus does support DMA between devices.

In other words, the transfer over the PCI bus to the USB Controller supports DMA (using the buss's DMA controller), but transfers over USB itself do not support DMA. It's one of the biggest differences between Firewire and USB (and a cool trick is that you can use Firewire to read the memory of a system without any software support using purely DMA and the right Firewire commands. Firewire is much more of a self-organsing buss that makes this possible).

Of course, if the CPU in the KRONOS is communicating with the USB controller purely through interrupt-driven polling rather than DMA, that's an area of opportunity, which I believe may be what you mean?

Am I making any sense whatsoever?

Have a good day at work - only a few more days until the weekend

Heider · Post by **Heider** » Thu Jul 05, 2012 11:34 am

SeedyLee wrote: ...
In other words, the transfer over the PCI bus to the USB Controller supports DMA (using the buss's DMA controller)...

... that's it!, ... that's the one!

You are making sense Sandy(uuuuuhhhh, typ'o again, I meant Seedy)Lee...

The USB you described initially is how the USB-Polling mode works, which is correct, however, USBs can work through DMAs, it's kina like what you are saying above mate. I think we're talking the same thing, the idea is; "the Bus is abused by -a- controller that is not the CPU, which handles the I/O to transfer data to the memory"...

In this context; Double-buffering means: place another buffer somewhere, use that to prepare things (slice-and-dice the scenes, build the drums kits, etc), and then prepare to play that instantly when requested by the user,

This is rather than the current action when a user use another set-list item when the rhythem is playing already: "Stop playing", "Overwrite the same Buffer", and then "Wait for the poor SOD to press Play", and maybe-then... "Play"...

I quote what Roblof mentioned about SHARK hardware, there is a memory buffer there, it was 1gb if I remember correctly,... this "in theory" should support building up all full configurations for a complete set-list screen (16 programs/combis), ready for pressing any of those to "continue" playing non-stop...

Whoever is reading this, believe me, this "can" be done...

... Back to work,... lunch time is over...

Kind Regards
Heider

1jordyzzz · Post by **1jordyzzz** » Thu Jul 05, 2012 5:05 pm

but im confused...
if the direct sample play from the SSD requires mobo and shark, would the USB become the bottleneck???
so, based on my dumb basic knowledge, i suppose this is the route to stream samples from SSD
SHARK --> USB --> CPU --> SSD --> CPU --> USB --> SHARK --> output bus

is the USB connection still become the bottleneck??? what about if there are 4 instance of SGX 1 + 2 ex11 (legendary string) running at the same time (all uses SSD)???
is that one of the the reason why korg didn't make user sample streaming available??

Heider · Post by **Heider** » Thu Jul 05, 2012 5:16 pm

Hi 1jordyzzz,...

Sorry to ask you a dumb question,... but what is "SSD"?!... Which menus to access it?

I initially thought SSD you are talking about the SD Ram, which goes straight into MOBO (USB(SD) -> MOBO -> USB(SHARK) ...

But I can see clearly you are talking about something else here, again, sorry for the dumb question.

Thanks
Heider

Luk84PL · Post by **Luk84PL** » Thu Jul 05, 2012 5:57 pm

Heider wrote:Hi 1jordyzzz,...

Sorry to ask you a dumb question,... but what is "SSD"?!... Which menus to access it?

I don't know if you were sarcastic with your question but SSD means Solid State Disk which refers to internal HDD drive...

Any ways I'm holding my thumbs tight for your glorious mission my friend

roblof · Post by **roblof** » Thu Jul 05, 2012 6:10 pm

Ssd is the solid-state drive (i.e. The 30gb harddisk).

Luk84PL · Post by **Luk84PL** » Thu Jul 05, 2012 6:34 pm

roblof wrote:Ssd is the solid-state drive (i.e. The 30gb harddisk).

"Disk" - "Drive" = "Potato" - "Tomato"... no difference

Heider · Post by **Heider** » Thu Jul 05, 2012 6:35 pm

Sorry Guys, I guess I am REALLY tired tonight with all the work that I honestly forgot what SSD means!!!... Yes, I know all about that... but just simply forgot...

Therefore, the answer to 1jordyzzz's question is:

SSD -> MOBO -> SHARK via Output bus (Which is the Usb Bus)...

and not:

SHARK --> USB --> CPU --> SSD --> CPU --> USB --> SHARK --> output bus

Therefore, yes indeed, USB "is" the bottleneck, however, since USB is quite fast here, it can cope with the little audio data. Think about USB video-tuner cards, they cope a lot more than that... !

Kind Regards
Heider