From: Patrick Ziegler <patrick.ziegler@fh-kl.de>
To: alsa-devel@alsa-project.org
Cc: Alex <lee188@singnet.com.sg>
Subject: Re: SoC Atmel SSC stereo problem
Date: Mon, 25 Oct 2010 11:16:36 +0200 [thread overview]
Message-ID: <4CC54AF4.9050808@fh-kl.de> (raw)
In-Reply-To: <loom.20101023T054800-433@post.gmane.org>
Hi Alex,
>> The SSC is connected to a FPGA that assigns the bus to different devices
>> depending on the application. And for all applications the FPGA
>> generates the clocks. Maybe this is not the best solution but I will try
>> to deal with this limitation first before I try to persuade other people
>> to change it.
>>
>>
> Hi Patrick,
>
> It looks like you are running the SSC TX in slave mode, with both the SCLK (the
> i2S clock) and LRCK provided by your FPGA. It is trickier to prevent channel
> inversion in this mode.
>
> One possible is to:
>
> (1) test for the LRCK level with a gpio pin connected to the LRCK. This should
> normally be the same pin assigned to TX_FRAME_SYNC. After any USB set interface
> to the alternate setting for playback of your active device, or after any
> sampling rate change etc., you re-sync the transfer to the correct LRCK edge:
>
> pdca_disable(PDCA_CHANNEL_SSC_TX);
>
> // reset the audio buffer pointers to the start of the LEFT channel etc
> // if required
>
> // re-sync SSC to LRCK
> // Wait for the next frame synchronization event
> // to avoid channel inversion. Start with left channel - FS goes low
>
> while (!gpio_get_pin_value(_LRCK));
> while (gpio_get_pin_value(LRCK));
> // exit when FS goes low
>
> // Enable now the transfer.
> pdca_enable(PDCA_CHANNEL_SSC_TX);
>
> (2) start clocking data out at any LRCK edge after a suitable delay (of 1
> SCLK). You may need to use LRCK level change rather than any edge depending on
> the hardware timing. The delay may also need to be adjusted depending on
> hardware timing.
>
> (3) clock out one sample (either left or right) per LRCK edge (or level).
>
> Of course, if you are running the SSC in master mode, there are easier ways to
> ensure channel synchronization :-)
>
> The above suggestion is extrapolated from my project using the AT32UC3A3 which
> has a similar (more capable) SSC as the AT91. So it may or may not work for
> you.
>
>
Thank you for your suggestion, I will try to adept this approach for our
needs.
Best regards
Patrick
--
Dipl.-Inf. (FH) Patrick Ziegler
University Of Applied Sciences
Kaiserslautern
Amerikastrasse 1
D-66482 Zweibruecken
Germany
Phone: +49 631 3724 5526
Mail: patrick.ziegler@fh-kl.de
http://www.fh-kl.de
http://www.fh-kl.de/fachbereiche/imst/iuk-knowhow.html
prev parent reply other threads:[~2010-10-25 9:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-22 15:17 SoC Atmel SSC stereo problem Patrick Ziegler
2010-10-22 16:11 ` Clemens Ladisch
2010-10-22 21:39 ` Patrick Ziegler
2010-10-23 4:10 ` Alex
2010-10-25 9:16 ` Patrick Ziegler [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CC54AF4.9050808@fh-kl.de \
--to=patrick.ziegler@fh-kl.de \
--cc=alsa-devel@alsa-project.org \
--cc=lee188@singnet.com.sg \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.