TMDSLCDK6748: Pop noises on example USB_DevAudio_lcdkOMAPL138_c674x

Hi Jp,

Are you using the example CCS project from the PDK, i.e. pdk_omapl138_1_0_11\omapl138_c6748_ccs_projectspecs\ccs_examples\windows\OMAPL138\USB_DevAudio_lcdkOMAPL138_c674xExampleProject.projectspec?

Thanks,

Jianzhong

Hello,

Thanks fo the reply. I don't have such example. My example is located in C:\ti\pdk_omapl138_1_0_11\packages\MyExampleProjects\USB_DevAudio_lcdkOMAPL138_c674xExampleProject , generated with the pdkProjectCreate.bat script as described in section '1.4.5.1.5. PDK Example and Test Project Creation' of the 'Processor SDK RTOS' Documentation

Hi, I update my message. I installed the folder of the projectSpecs and imported the project from there. The same problem still occurs. I attatch a recording of this problem.

Thanks again

Jp

Hi Jp,

Thanks for sharing your recording. I'll look into this issue and consult internal team. I hope to get back to you by the end of this week.

Thanks for your patience.

Regards,

Jianzhong

Ok! Thank you very much. I tried changing the buffer sizes and the pop noises change slightly, a bigger buffer 

#define AUDIO_BUFFER_SIZE       (AUDIO_PACKET_SIZE*80)

makes the noises appear each two seconds instead of one. But they are still there.

Thanks again, I keep waiting then.

Jp

Hi Jp,

I'm working toward reproducing this problem on my omap-l138 lcdk. I don't have a proper JTAG to connect the board through CCS, so it will likely take me some time.

Meanwhile, your latest finding points to possible issues with audio sample buffering rather than USB driver. Can you try to increase AUDIO_BUFFER_SIZE again if memory permits? If that further reduces the frequency of pop noise, that should give us more confidence that the USB driver works fine and we can focus on looking into data buffering. For example, maybe there are some issues when  the audio sample buffer wraps around.

Thanks for your patience.

Regards,

Jianzhong

Thanks again. Yes, increasing the buffer size (I tried a size of 400*AUDIO_PACKET_SIZE ) reduces the frequency of pop noises. I'm sure it's data buffering because this noise does not happen the other way (Mic input recording)

Edit: There is a phase changing happening suddenly, I guess each time the buffer is filled. This is what I recorded with Audacity. The original signal is a tone of 440 Hz (up) the other two were directly copied to the recording buffer once the first one is filled.

WWith this buffer size (which is 400*384 = 154k size of char, quite big)this happens each 16-17 seconds approx.

Is the distance between two adjacent glitches always equal to the buffer size? Do the glitches look the same or different?

Data copying shouldn't change the samples, but buffer overflow/underflow could lose samples or insert random values.

Hi,

I made some more recordings. The distance between two glitches is always the same - given a fixed buffer length - so for instance the one in my previous post happens every 17 seconds. The buffer size 0.8 seconds (calculated based on AUDIO_BUFFER_SIZE = AUDIO_POCKET_SIZE*400 = 153.600, in char size which is the defined size)

They look kind of the same. In this case we have a glitch at 0:34 and 0:51

If I reduce the buffer size to AUDIO_PACKET_SIZE*100 then the glitches appear each 4.2 seconds approximately which makes sense. 

Glitches kind of look the same, it is an abrupt phase changing in the sound. I agree in the possble overflow or underflow, seems like it is not taking the exact amount of samples when sending to the codec. Could it be the problem?

thanks again

Jp

Hi Jp,

I consulted a few people internally who know more about this USB example and believe this glitch is caused by clock difference between the host USB and the audio codec on the OMAP-L138 LCPD.

Because the two clocks are not synchronized, they operate at slightly different frequencies. Therefore, the read and write to the audio sample buffer are running at different rates. If write is faster than read, the write pointer will lead the read pointer more and more. Eventually the write pointer will wrap around and gradually catch up with the read pointer. When the writer pointer overtakes the read pointer, a glitch will be produced.

Since this is an example code to demonstrate how to use the USB driver for audio, it doesn't have asynchronous sampling rate conversion (ASRC) which would have prevented the glitches. To avoid the glitch completely, you'll need to implement ASRC in the code. 

Hope this clears things out.

Thanks and regards,

Jianzhong

Hello Jianzhong,

Thank you for the answer. Then the reason of the glitches totally makes sense and that's it. Only thing to know, why is it not already implemented in the example? If there would be always discrepancies between both clocks, it's necessary to have an ASRC. Is there any code already made or do I have to implement it from scratch? The c6748 doesn't have an ASRC module so I believe it has to be implemented digitally at the lowest level.

Thanks again,

Javier

Hello,

By the way we have another issue with this example. I don't know if i can ask in this same thread, if not, I can open a new one.

Connecting it to Windows works fine (forgetting about the sampling rate glitches issues), but on Mac (which we need) the debugger throws this error:

A0=0x0 A1=0xc3020ac0
A2=0xffffffff A3=0xc3278244
A4=0xc3278010 A5=0x2a
A6=0x3 A7=0x294
A8=0xc32669e6 A9=0xc32e3d68
A10=0xc327cf08 A11=0xc327cf08
A12=0x0 A13=0xc301f798
A14=0xc3020c28 A15=0x0
A16=0x180 A17=0xc3019770
A18=0x0 A19=0xf
A20=0x0 A21=0x0
A22=0x18d091ce A23=0xdeefff2d
A24=0x0 A25=0x4589d809
A26=0xece511 A27=0x398145bb
A28=0xbf2fab74 A29=0x2
A30=0xc3266a14 A31=0x234
B0=0x1 B1=0x0
B2=0x0 B3=0xc30166ac
B4=0xc3278244 B5=0x0
B6=0x29 B7=0x2b
B8=0x2d B9=0x0
B10=0xc32e31d0 B11=0x0
B12=0x1 B13=0x1f
B14=0xc32e6b40 B15=0xc32c55b0
B16=0xc327cf08 B17=0x0
B18=0x1e00020 B19=0x200
B20=0x14 B21=0x15
B22=0xf B23=0x0
B24=0x1f B25=0x4c
B26=0x0 B27=0x0
B28=0xc327cf08 B29=0xc327cf08
B30=0xc32e68a4 B31=0xc327cf08
NTSR=0xc32e4a36
ITSR=0x0
IRP=0xc32c5590
SSR=0xf
AMR=0xc32e4210
RILC=0x1
ILC=0x0
Exception at 0x0
EFR=0x2 NRP=0x0
Internal exception: IERR=0x1
Instruction fetch exception
xdc.runtime.Error.raise: terminating execution

This happens when executing the code and the USB connection is trying to stabilize. I'm trying to find the origin of this. I read some threads with the same exception but the origin is not the same

Thanks again,

Jp

Ok, perfect then! Thanks