Hello Caleb
Le 09/01/2016 01:47, Caleb Crome a écrit :
[...]
Hello Arnaud,
I have finally gotten to test your patches, and I'm still having
trouble with channel slips.
I applied your v2 patch set, along with your changes for using a dummy codec.
The full changes are here:
https://github.com/ccrome/linux-caleb-dev/tree/v4.4-rc8-armv7-x3
This ignores most of my previous patches, and uses your code to bring
up the SSI (without a codec) on a wandboard.
I am using SSI3, and doing a hardware loopback between TX and RX.
Here's what I run:
./atest -r 16000 -c 8 -p 2048 -D default play
which plays continuously.
and in another shell:
./atest -r 16000 -c 8 -p 2048 -D default -d 10 capture
which captures for 10 seconds.
The first time I run the capture command, it succeeds, no problem.
dbg: dev: 'default'
dbg: default: capture_start
dbg: start a 10 seconds duration timer
warn: First valid frame
warn: 3400 3401 3402 3403 3404 3405 3406 3407
dbg: end of tests
total number of sequence errors: 0
global tests exit status: OK
But the second and all subsequent captures, it fails with channel slips:
dbg: dev: 'default'
dbg: default: capture_start
dbg: start a 10 seconds duration timer
err: invalid frame after 0 null frames
err: d2a1 d2a2 d2a3 d2a4 d2a5 d2a6 d2a7 d2c0
err: d2c1 d2c2 d2c3 d2c4 d2c5 d2c6 d2c7 78e0
dbg: end of tests
total number of sequence errors: 430080
global tests exit status: OK
Can you use -I option to get a little more log of the error
$ ./atest -r 16000 -c 8 -p 2048 -D default -d 10 -I 10 capture
Just to know if the wrong frames comes from the previous record session,
meaning the RX fifo was not cleared correctly,
as if the CCSR_SSI_SOR_RX_CLR bit is not working as we might expect.
(ie. d2a1 .. d2c7 may come from the previous recording, and 78e0 .. may
be the start of the new recording session)
May be you can read the RX fifo level just avec applying
CCSR_SSI_SOR_RX_CLR to assert the fifo is really empty ?
In case it is still not empty, we will still have the possibility to
empty the fifo by ready the samples one by one manually.
Regards,
arnaud
I verified with a scope that the data on the data bus is correct, the
problem is with restarting RX, the RX doesn't synchronize to the frame
sync. BTW, the RX slot is random. 1/8 times or so, the restarted
capture actually works.
My setup is a single core wandboard (i.mx6 solo), with J1.16 jumpered
over to J1.20 (tx->rx)
Thanks for the patches and for the atest program! It's really handy :-)
So, I have not messed with water marks, dual fifo, etc with your patches yet.
Any other patches that you think might need to be applied to make the
RX restart work?
-Caleb
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
