[alsa-devel] [PATCH] ASoC: samsung: In the i2s_set_sysclk() callback we are currently clearing all bits of the IISMOD register in i2s_set_sysclk. It's due to an incorrect mask used for the AND operation which is introduced in commit a5a56871f804edac93a53b5e871c0e9818fb9033 (ASoC: samsung: add support for exynos7 I2S controller) and also adds the missing break statement.
Cc: Sylwester Nawrocki s.nawrocki@samsung.com Signed-off-by: Sylwester Nawrocki s.nawrocki@samsung.com Signed-off-by: Padmavathi Venna padma.v@samsung.com --- sound/soc/samsung/i2s.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c index 0df6547..e1ace52 100644 --- a/sound/soc/samsung/i2s.c +++ b/sound/soc/samsung/i2s.c @@ -494,7 +494,7 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai, if (dir == SND_SOC_CLOCK_IN) mod |= 1 << i2s_regs->cdclkcon_off; else - mod &= 0 << i2s_regs->cdclkcon_off; + mod &= ~(1 << i2s_regs->cdclkcon_off);
i2s->rfs = rfs; break; @@ -551,10 +551,11 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai, }
if (clk_id == 0) - mod &= 0 << i2s_regs->rclksrc_off; + mod &= ~(1 << i2s_regs->rclksrc_off); else mod |= 1 << i2s_regs->rclksrc_off;
+ break; default: dev_err(&i2s->pdev->dev, "We don't serve that!\n"); return -EINVAL;
Hi,
On 11/20/14, Padmavathi Venna padma.v@samsung.com wrote:
Cc: Sylwester Nawrocki s.nawrocki@samsung.com Signed-off-by: Sylwester Nawrocki s.nawrocki@samsung.com Signed-off-by: Padmavathi Venna padma.v@samsung.com
sound/soc/samsung/i2s.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c index 0df6547..e1ace52 100644 --- a/sound/soc/samsung/i2s.c +++ b/sound/soc/samsung/i2s.c @@ -494,7 +494,7 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai, if (dir == SND_SOC_CLOCK_IN) mod |= 1 << i2s_regs->cdclkcon_off; else
mod &= 0 << i2s_regs->cdclkcon_off;
mod &= ~(1 << i2s_regs->cdclkcon_off);i2s->rfs = rfs; break;
@@ -551,10 +551,11 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai, }
if (clk_id == 0)
mod &= 0 << i2s_regs->rclksrc_off;
mod &= ~(1 << i2s_regs->rclksrc_off);else mod |= 1 << i2s_regs->rclksrc_off;
break;default: dev_err(&i2s->pdev->dev, "We don't serve that!\n"); return -EINVAL;
-- 1.7.4.4
Please ignore this patch as subject line is not proper.
Thanks Padma
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
I was trying to find a bug in the timestamping logic I am working on and after some time I realized the USB audio class driver seems to have an issue. If I instrument the code in sound/usb/pcm.c, I see a offset of up to 6ms between the snd_usb_substream_playback_trigger and prepare_playback_urb steps
[45053.102625] trigger_start [45053.108320] prepare_playback_urb
My understanding is that empty URBs are submitted in the prepare step to avoid underflows, which is fine. The problem with that is that the trigger_tstamp value is captured before audio transfers actually start and there is a constant offset when trying to track audio/system time drifts or do basic a/v sync.
Any suggestions on how to fix this? I can't figure out if this is an off-by-one error or another bug. Feedback welcome. -Pierre
Pierre-Louis Bossart wrote:
I was trying to find a bug in the timestamping logic I am working on and after some time I realized the USB audio class driver seems to have an issue. If I instrument the code in sound/usb/pcm.c, I see a offset of up to 6ms between the snd_usb_substream_playback_trigger and prepare_playback_urb steps
[45053.102625] trigger_start [45053.108320] prepare_playback_urb
My understanding is that empty URBs are submitted in the prepare step to avoid underflows, which is fine. The problem with that is that the trigger_tstamp value is captured before audio transfers actually start and there is a constant offset when trying to track audio/system time drifts or do basic a/v sync.
Most other devices have a FIFO that gets filled quickly when the stream is started. This results in a small offset in the opposite direction.
AFAICS you cannot avoid having an offset when trying to relate the trigger_tstamp value to the sample clock.
Regards, Clemens
participants (4)
-
Clemens Ladisch -
Padma Venkat -
Padmavathi Venna -
Pierre-Louis Bossart