TAS1020B - Buffer size for ISO EP1 problem

Unfortunately, the data sheet for the TAS1020B is remarkably vague about buffer sizing. It says that the isochronous endpoint buffers are circular. However, the eval code shows that the buffer sizes are set to exactly the packet size (stereo 16 bit/48 kHz samples need 192 bytes per 1 ms frame). This pretty much goes against how the data sheet tells us the DMA engines operate. See section 2.2.7.4.1. Basically, we are told that the DMA controller "could begin immediately retrieving data and outputting it (sic) to the C-Port. However, the DMA channel waits until the next USB SOF is received." At this point, a full packet of data is sitting in the buffer. Furthermore, after receiving that next SOF, the DMA channel waits "until the next C-port frame" (start of next sample) "and then begins transferring the buffered data to the C-Port."

So what this tells me is that there must be some amount of extra space in the DMA buffer to allow for the time between the SOF and the start of the next sample, otherwise a sample may be lost. The buffer needn't be double the size of the packet but also it can't be exactly the packet size, either. Since I do not have the eval platform, I cannot verify that the provided code actually works.

InDesign's tech support was entirely useless when asked directly: "How big should the DMA buffer be, given a particular, known sample frequency and word size?"

Basically, support for this part sucks ... which is proven if you've tried to understand the documents in the firmware developer's kit. Your English is better than the eval code!

good luck.

Jaroslaw,

We're trying to dig up something about this in the archives (i.e., addressing limitations).

When you say you have a max frame size of 576, I'm guessing that even though Mode 4 supports 2ch out and 4ch in, you're only using 2ch out, and are doing 96kHz 24-bit stereo out.

In the mean time, though, you can take some advantage of the fact that it takes a finite amount of time to actually transfer the data via USB 1.1.  There's no guarantee in USB as to when in the 1ms frame the host will perform the isochronous transfer (so you have to assume worst-case) but it will move the data sometime during the 1ms frame.  So, say the host provided 576 bytes during frame (i).  At the SOF that ends that frame, the codec engine will start playing-out that data to the DACs over the next 1ms frame.  Worst-case, the host could start sending you over USB the next 576 samples right at after the SOF.  If it did that, at 12Mbps, it would take 384usec to receive that next chunk, at which point 221 bytes of the 576 bytes received during frame (i) have been sent out by the codec engine.  So, you need 576 bytes to hold the frame (i+1) data, plus 576-221=355 bytes still unsent (subtotal: 931), plus some small amount for roundoff error (and to allow for some miss-match between the codec engine clock and the host clock, as addressed by the softPLL).  I'd double-check this logic/arithmetic, but if 1008 is working for you I'd go with it, at least until I've sifted through the archives.

Regards,

Frank  

Andy,

The complication as I understand it is that the host is not under any obligation to perform the isochronous transfer at the same point in the frame, from one frame to the next.  Hence, some double-buffering is required (else, the codec interface could be starved for data if the host is sending the audio) or the USB engine could be starved if the device is sending the audio. 

Regards,

Frank

Frank,

Yes, I use only 2 channels for doing 96kHz/24Bit out. In channels ale disabled.

I try to implement asynch transmision with feedback.

As an engineer looking for answers why buffer larger ten 1008bytes don't work.

I performed the following two tests:
1A - after reset TAS1020b i fill EP1 buffer with value 0xAA (max size=1152 bytes)
2A - initalize EP1 with buffer size 1008 bytes
3A - play music (OK)
4A- stop
5A - test buffer content and I saw then only 1008 bytes changed (OK)

1B after reset TAS1020b i fill EP1 buffer with value 0xAA (max size=1152 bytes)
2B - initalize EP1 with buffer size 1024 bytes
3B - play music (distorted)
4B stop
5B - test buffer content and I saw then only 1024 bytes changed (OK)
It looks like a circular buffer works correctly, but music is distorted.

I try to test Read/Write DMA Pointer (Read Only registers) and in same cases they are outside declared buffer and implemented RAM !

Another important question is how to read properly Read/Write Pointer for DMA Channel 0 (CH0RDPTR,CH0WRPTR).
Each of them consists of two parts LO and HI. Which part should be read first.
What happens if, between reading LO and HI the new will come (new ISO transfer) and pointer changed.
Is atomic method of reading this registers?

Best regards
Jaroslaw Czula
Poland

Frank Minich said:

Andy,

The complication as I understand it is that the host is not under any obligation to perform the isochronous transfer at the same point in the frame, from one frame to the next.  Hence, some double-buffering is required (else, the codec interface could be starved for data if the host is sending the audio) or the USB engine could be starved if the device is sending the audio.

Frank, I agree that double-buffering is necessary. My main beef is that all of the examples in the eval code have the buffer sizes set to exactly the endpoint packet size, which means that the eval kits shouldn't work, and also the device documentation should make this clear. As I don't have one of the eval kits here, I cannot test it.

Thanks,

-a

Andy,

You are wrong, in evaluation software (ver1.8) double buffering is used.

Declaration in:

"devmap.h":
#define OUTEP1_RSIZE          0x180     // 16 bit 48 kHZ stereo max   (384= 2*192bytes)
#define OUTEP1_SIZE             (OUTEP1_RSIZE >> 3)   /(register format)

"devdesc.c" Endponit decsriptor
OUTEP1_RSIZE >> 1                              // Max packet size   (384/2 =192)

Device.h
OEPBSIZ1 = OUTEP1_SIZE;                // 384 bytes

So max pocket size is declared 192bytee and EP1 buffers size is 384 bytes.
We have full double buffering

Maybe someone knows the software that allows to send individual ISO frame to device?

Questions about buffer larger then 1008bytes and atomic method of reading RD/WR pointers are still valid.

Best regards
Jaroslaw Czula
Poland

Andy,

As Jaroslaw points out, the computation made in devmap.h comes up with OUTEP1_RSIZE and INEP2_RSIZE as 2x the bytecount to be transferred each frame, and OEPBSIZ1 and IEPBSIZ2 are set to 1/8 of these, since "this value should be in 8 byte units".

I can assure you that I have loaded the v1.8 source from the FDK into the Keil uVision tools, rebuilt, blown into the TAS1020BEVM flash, and verified that the code results in a working implementation.

Regards,

Frank

Jaroslaw,

Your test looks reasonable, but let me ask you a few questions.

It's not clear from what you have said how much of the Firmware Development Kit application you are using.  Normally, TAS1020B users modify the FDK application, since that is the easiest way to take advantage of the ROM contents.

Ok, so you say that you "try to implement asynch transmission with feedback".  That's a viable approach, but it's inconsistent with the approach taken in the FDK application in regard to SoftPLL.  Have you actually started to implement asynch transmission with feedback?  Have you reworked the logic in SoftPLL so that it does _not_ adjust the clock divider for the CODEC (or are you using some other clock for the CODEC)?

As to how to read the DMA read/write pointers - you could just read them till they are the same on two successive reads, or read them in the SOF interrupt.

Regards,

Frank

Frank Minich said:

Andy,

As Jaroslaw points out, the computation made in devmap.h comes up with OUTEP1_RSIZE and INEP2_RSIZE as 2x the bytecount to be transferred each frame, and OEPBSIZ1 and IEPBSIZ2 are set to 1/8 of these, since "this value should be in 8 byte units".

I can assure you that I have loaded the v1.8 source from the FDK into the Keil uVision tools, rebuilt, blown into the TAS1020BEVM flash, and verified that the code results in a working implementation.

Regards,

Frank

OK, I went back and checked, and indeed the v1.8 firmware for the eval kit indicates that the buffer sizes are set to double-buffer on both directions.

However, and I think this is where I was getting confused, the TSC2100_FW8 code does not double-buffer. And there are some interesting differences between the standard eval kit and the TSC2100 kit, in things like how the SetIf() handler works (the 1.8 code stalls the endpoint when the interface is set to the zero-bandwidth default, for instance).

Anyways, thanks for setting me straight on this detail.

-a

Andy,

It looks to me like the TSC2100_FW8 source does nothing but muddy the water.  Do you see any reason why it needs to be in the FDK?

Thanks!

Frank

Frank Minich said:

Andy,

It looks to me like the TSC2100_FW8 source does nothing but muddy the water.  Do you see any reason why it needs to be in the FDK?

Muddy waters, indeed.

That bit of code does have a good example of how to use the endpoint interrupt to indicate than an HID endpoint has new data, and how to handle those new data.

But if you're seriously considering updating the FDK, start with the TAS1020_FirmwareApplicationNote.pdf, which is incomplete and somewhat confusing. Start by clarifying what stuff is for TAS1020 vs A vs B. Then clean up the missing links, as in page 7 has "Figure xxxx." Then expand on Chapter 5 and explain what's going on. Clarify the TAS1020 ROM Memory Map in Chapter 6, which has UsbRequest starting in PDATA space at 0xFA00 yet the ROM source code puts it in data space starting at 0x6E. ExternalData is documented to start at 0xFA30 yet the ROM source puts it at 0xFA1E. And in 7.3.2, Required PDATA Defines, UsbRequest is put _at_ 0xFA10 and ExternalData is _at_ 0xFA40.

I mean, that document is completely inconsistent in many places and it's maddening.

Thanks for paying attention to my bitching and moaning.

-a

Frank Minich said:

Jaroslaw,

Your test looks reasonable, but let me ask you a few questions.

It's not clear from what you have said how much of the Firmware Development Kit application you are using.  Normally, TAS1020B users modify the FDK application, since that is the easiest way to take advantage of the ROM contents.

Ok, so you say that you "try to implement asynch transmission with feedback".  That's a viable approach, but it's inconsistent with the approach taken in the FDK application in regard to SoftPLL.  Have you actually started to implement asynch transmission with feedback?  Have you reworked the logic in SoftPLL so that it does _not_ adjust the clock divider for the CODEC (or are you using some other clock for the CODEC)?

As to how to read the DMA read/write pointers - you could just read them till they are the same on two successive reads, or read them in the SOF interrupt.

Regards,

Frank

Hi,

Based on the available examples (TAS1020B firmware V1.8, TUSB3200  firmwareV1.01) i wrote my own firmware and  I don't use ROM function.
I also build my prototype board.
Maybe I'm old fashioned but I like to have control over the entire code.

The Asynch mode is in future plans (2 external generators 24,576MHz and 22.5792MHz conected to MCLKI) and feedback Endpoint.

At  this moment I work in adaptive mode and try to solve all the doubts.
Soft PLL procedure code is not fully understood for me.
Why do we have in the code:
     EngFrq = EngFrq - (((EngAcgAcc >> 8) + (EngAcgAcc - EngOldAcgAcc)) << 1);
Rather, I would expect such code
  EngFrq = EngFrq - ( (EngAcgAcc - EngOldAcgAcc) << 1);

Yesterday I made additional tests with the transmission of individual ISO frames to see how WR/RD pointers are changing.
And the results are surprising.

Test 1:
Max Frame Size 576 byte,  Buffer Size 1008 Bytes, Data Frame all bytes equal 0xAB
After transmision I saw in buffer 576 bytes equal 0xAB and pointers increased by 576 bytes,. All OK

Test2.
Max Frame Size 576 byte,  Buffer Size 1152 Bytes, Data Frame all bytes equal 0xAB
After transmision I saw in buffer  only 132 bytes equal 0xAB and pointers increased by only 132 bytes,. ERROR

Today I will tray test with another buffer sizes.

About reading pointers, is the difference between readig Lo-Hi, Hi-Lo?
The simplest method is:

MOV DPTR,#CH0RDPTRH
MOVX A,@DPTR
INC DPTR
MOV B,A
MOVX A,@DPTR

But we have 2 instruction between reading, is it Ok?

Best regards
Jaroslaw Czula
Poland

> Maybe I'm old fashioned but I like to have control over the entire code.

That's impractical with the TAS1020B, since the part was devised intentionally as a cost-reduced part.  RAM costs more than ROM, so functionality was moved to ROM where possible.  The source for the ROM is in the FDK.  If you want to write it all, you might need to switch to the TUSB3200, which has more RAM and is targeted specifically to that usage.

>   Why do we have in the code:
     EngFrq = EngFrq - (((EngAcgAcc >> 8) + (EngAcgAcc - EngOldAcgAcc)) << 1);
> Rather, I would expect such code
  EngFrq = EngFrq - ( (EngAcgAcc - EngOldAcgAcc) << 1);

There's some digital filtering going on, I think.

> Max Frame Size 576 byte,  Buffer Size 1152 Bytes, Data Frame all bytes equal 0xAB
> After transmision I saw in buffer  only 132 bytes equal 0xAB and pointers increased by only 132 bytes,. ERROR

I haven't had time to set up this experiment, sorry.  Do you have a USB sniffer?  How are you sending a _single_ iso packet?

> About reading pointers, is the difference between readig Lo-Hi, Hi-Lo?

Those registers really are in RAM.  Shouldn't make a difference in which order you read them.

Regards,

Frank

Frank,

My application is smaller then 6kB.

Yes, I use "snoopy sniffer", with my own software for fitering information.

I tried to get help form "TI Europe Technical Support", but I was redirected to InDesign .
At this moment I don't have answer from them.

Best Regards
Jaroslaw Czula
Poland

Jaroslaw Czula said:

My application is smaller then 6kB.

Yes, I use "snoopy sniffer", with my own software for fitering information.

I tried to get help form "TI Europe Technical Support", but I was redirected to InDesign .

At this moment I don't have answer from them.

InDesign aren't very helpful.

-a

Frank.

After a week I have not received ANY response from InDesign.

I do not understand why Ti promotes this type of business partners and why redirects technical support outside TI.

Best regards
Jaroslaw Czula
Poland

Hi All,

I finished my project "TAS1020B based USB to I2S/SPDIF asynchronous converter".

The result you can see here:

http://www.diyaudio.com/forums/digital-source/206626-tas1020b-based-asynchronous-usb-i2s-spdif-converter-24bit-96khz.html

Thank you all for your help.

Best regards
Jaroslaw Czula
Poland