Hi, i have read most of the audio software design reference manuals, and most of the time, they come up with something called a decoupler. According to the USB audio software design guide, what the decoupler does is: "Manages delivery of audio packets between the endpoint buffer component and the audio components. It can also handle volume control processing."
I know this is a technical question, but it would really help me to understand what they mean by delivery. Can't the audio component simply read onto the buffer? Also, i have seen the use of a decoupler in an AVB design. Are they both the same thing? Personally, i think it has to do with queuing up samples into FiFo's but a more detailed explanation would be welcome. Thanks in advance!
what is a decoupler? Topic is solved
-
pasau
- Experienced Member
- Posts: 77
- Joined: Fri Dec 06, 2013 7:05 pm
-
infiniteimprobability
- XCore Legend
- Posts: 1126
- Joined: Thu May 27, 2010 10:08 am
Passau - you're on the right track. It's all about buffering. You'll see that, in the refrerence design, both decouple and buffer (which are tasks run in thier own cores) belong in the usb_buffer directory. The reason for needing them is as follows - both the audio.xc (basically an I2S core with extra features like I2C configuration and DSD modes) and XUD (handles all of the low level USB transactions) are server tasks which are sensitive to blocking.
This is because they are both very high performance (usb = 480Mbps and I2S can handle 20 ch of 192KHz, 32b audio) and so any communications must be short and non-blocking (ie. you can't think about a request for data too long). If you stall communications with either of these then you can break timing in I2S or USB, because thier inner loops must service the I/O at a certain rate.
Breaking timing is bad as either USB won't meet spec or I2S will have gaps in streamining. So USB/I2S each has task to service them, which is always responsive, and keeps them running smoothly.
However, in USB Audio, USB and I2S do not run at exactly the same rate, so you need a buffer between them. Both buffer and decouple talk to each other via a shared memory FIFO between them. So effectively you have logical cores/tasks running:
USB <-> Buffer <-> Decouple <-> I2S
which is really something like this:
server <-> client <- FIFO-> client <-> server
You'll notice that decouple also handles other tasks like packing/unpacking (eg. USB Audio class 1 where 24b samples are not long word aligned) and volume control. So there's a bit of slack in these buffer tasks for stuff, as long as they always responsive to thier respective servers. This is why we use an interrupt handler in decouple.
If the performance of the system was much lower, then it may be possible to add the buffering into server tasks, but high speed USB and I2S with that many channels and data rate pushes the timing budget, so we add buffering to ensure it all works reliably.
This is because they are both very high performance (usb = 480Mbps and I2S can handle 20 ch of 192KHz, 32b audio) and so any communications must be short and non-blocking (ie. you can't think about a request for data too long). If you stall communications with either of these then you can break timing in I2S or USB, because thier inner loops must service the I/O at a certain rate.
Breaking timing is bad as either USB won't meet spec or I2S will have gaps in streamining. So USB/I2S each has task to service them, which is always responsive, and keeps them running smoothly.
However, in USB Audio, USB and I2S do not run at exactly the same rate, so you need a buffer between them. Both buffer and decouple talk to each other via a shared memory FIFO between them. So effectively you have logical cores/tasks running:
USB <-> Buffer <-> Decouple <-> I2S
which is really something like this:
server <-> client <- FIFO-> client <-> server
You'll notice that decouple also handles other tasks like packing/unpacking (eg. USB Audio class 1 where 24b samples are not long word aligned) and volume control. So there's a bit of slack in these buffer tasks for stuff, as long as they always responsive to thier respective servers. This is why we use an interrupt handler in decouple.
If the performance of the system was much lower, then it may be possible to add the buffering into server tasks, but high speed USB and I2S with that many channels and data rate pushes the timing budget, so we add buffering to ensure it all works reliably.