blackshard83
Posts: 82
Joined: Fri Jan 10, 2014 8:31 am

OMX Audio code working properly?

Fri Feb 19, 2016 4:53 pm

Hello all,

I'm working on an self-made audio engine which decodes/mixes multiple samples in realtime via software using the ARM.
I have solved all my problems excepts those regarding the interface to the RPi audio hardware. I have to use the OMX audio_render component because I don't (and can't) have ALSA or Jack.

Low latency is desired but not mandatory.

I followed the hello_audio source code and the engine plays and works well, except when it has to shutdown: using vcdbg reloc command there is always an 'ilin mapping buffer' which is not going to be freed and I don't understand why.

hello_audio example is not useful in such sense, because it is messy, poorly documented and often it leaves the videocore memory heap corrupted (like this):

Code: Select all

Relocatable heap version 4 found at 0x35000000
total space allocated is 140M, with 140M relocatable, 0 legacy and 0 offline
0 legacy blocks of size 2359296

free list at 0x3db74b60
139M free memory in 4 free block(s)
largest free block is 139M bytes

0x35000000: free 139M
[   6] 0x3db69e40: used 4.1K (refcount 1 lock count 0, size     4096, align   32, data 0x3db69e60, d1ruAl) 'ilin mapping buffer'
0x3db69e40: corrupt trailer (space 146189952 != 4161)
[  16] 0x3db6ae80: used 4.1K (refcount 1 lock count 0, size     4096, align   32, data 0x3db6aea0, d1ruAl) 'ilin mapping buffer'
0x3db6ae80: corrupt trailer (space 0 != 4161)
0x3db6ae80: corrupt trailer (guards[0] = 0x00000000)
0x3db6ae80: corrupt trailer (guards[1] = 0x00000000)
0x3db6ae80: corrupt trailer (guards[2] = 0x00000000)
0x3db6ae80: corrupt trailer (guards[3] = 0x00000000)
0x3db6ae80: corrupt trailer (guards[4] = 0x00000000)
[  10] 0x3db6bec0: used 4.1K (refcount 0 lock count 0, size     4096, align   32, data 0x3db6bee0, d1ruAl) 'ilin mapping buffer'
0x3db6bec0: corrupt trailer (space 0 != 4161)
0x3db6bec0: corrupt trailer (guards[0] = 0x00000000)
0x3db6bec0: corrupt trailer (guards[1] = 0x00000000)
0x3db6bec0: corrupt trailer (guards[2] = 0x00000000)
0x3db6bec0: corrupt trailer (guards[3] = 0x00000000)
0x3db6bec0: corrupt trailer (guards[4] = 0x00000000)
[  14] 0x3db6cf00: used 4.1K (refcount 0 lock count 0, size     4096, align   32, data 0x3db6cf20, d1ruAl) 'ilin mapping buffer'
[  18] 0x3db6df40: used 4.1K (refcount 0 lock count 0, size     4096, align   32, data 0x3db6df60, d1ruAl) 'ilin mapping buffer'
0x3db6df40: corrupt trailer (space 146206592 != 4161)
[  17] 0x3db6ef80: used 4.1K (refcount 0 lock count 0, size     4096, align   32, data 0x3db6efa0, d1ruAl) 'ilin mapping buffer'
0x3db6ffc0: free 18K
[   5] 0x3db74700: used  576 (refcount 1 lock count 0, size      512, align    4, data 0x3db74720, d0rual) 'ILCS VC buffer pool'
0x3db74700: corrupt trailer (space 146229568 != 577)
[   4] 0x3db74940: used  576 (refcount 1 lock count 0, size      512, align    4, data 0x3db74960, d0rual) 'ILCS VC buffer pool'
0x3db74940: corrupt trailer (space 576 != 577)
[   3] 0x3db74b80: used 537K (refcount 1 lock count 8, size   545792, align 4096, data 0x3db75000, d1rual) 'ARM FB'
[   2] 0x3dbfafa0: used  16K (refcount 1 lock count 0, size    16384, align   32, data 0x3dbfafc0, d0ruAl) 'audioplus_tmp_buf'
[   1] 0x3dbfefe0: used 4.0K (refcount 1 lock count 0, size        0, align 4096, data 0x3dbff000, d1rual) 'camera fast alloc arena'
heap corruption detected
small allocs not requested
Do someone know about well written and basic code to run and shutdown properly the OMX audio_render component?

Thanks
Last edited by blackshard83 on Mon Feb 22, 2016 9:34 am, edited 1 time in total.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6523
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: OMX Audio code working properly?

Fri Feb 19, 2016 5:29 pm

Have you done a cache flush ("vcgencmd cache_flush") before requesting the heap info?
The GPU and ARM have independent caches, so you could be seeing stale data from the ARM - it's normally the reason for seeing reported corrupt data in the allocation tables.

*edit* Correct flush command after doing a search for the correct syntax.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

blackshard83
Posts: 82
Joined: Fri Jan 10, 2014 8:31 am

Re: OMX Audio code working properly?

Mon Feb 22, 2016 8:19 am

No, I haven't. I'm going to try as soon as possible!

edit: got it, issuing cache_flush command removed the corrupt messages!

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6523
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: OMX Audio code working properly?

Mon Feb 22, 2016 10:00 am

It removed the "corrupt" messages, but did it also clear the ilin mapping buffers? ie do we still have an issue, or was it just the debugging approach?
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

blackshard83
Posts: 82
Joined: Fri Jan 10, 2014 8:31 am

Re: OMX Audio code working properly?

Mon Feb 22, 2016 3:55 pm

It removed the "corrupt" message.

About the "ilin buffer", it was an issue with ilclient library: I used ilclient_get_input_buffer() function to get the buffers to clean them *before* the actual audio_render callback. This caused some issues to ilclient library that refused to free all the buffers at shutdown.
From what I understood, ilclient library chains the buffers. Breaking the chain someway causes memory leaks.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6523
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: OMX Audio code working properly?

Mon Feb 22, 2016 5:29 pm

blackshard83 wrote:From what I understood, ilclient library chains the buffers. Breaking the chain someway causes memory leaks.
ilclient uses the pAppPrivate field to make a linked list of buffers. Corrupt that and you will get issues.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

blackshard83
Posts: 82
Joined: Fri Jan 10, 2014 8:31 am

Re: OMX Audio code working properly?

Tue Feb 23, 2016 9:18 am

Yes, I guessed it after. Actually I wan't corrupting the pAppPrivate field deliberately, it was a side effect of ilclient_get_input_buffer() calls.
At last I had to tweak ilclient library to add a memset() call to clear the buffers in ilclient_enable_port_buffers() function, right after the vcos_malloc_aligned() buffer allocation. I guess I could also pass a custom allocation function to ilclient_enable_port_buffers() to do the same without modifying the library...

Return to “OpenMAX”