Question about tsched=0 on PulseAudio

Question about tsched=0 on PulseAudio

[Kuninori Morimoto]

Hi ALSA ML

We noticed that our PulseAudio has crackling / skipping noise
which doesn't happen on normal aplay.
And it was removed if we do below

	load-module module-hal-detect tsched=0

According to google, it say

	tsched Since 0.9.11. Use system-timer based model (aka glitch-free).
	Defaults to 1 (enabled). If your hardware does not return accurate timing
	information (e.g. Creative sound cards) you can try to set tsched=0 to
	enable the interupt based timing which was used in 0.9.10 and before.

Here, what does this "return accurate timing information" mean ?
Is it struct snd_pcm_ops::pointer ??

Best regards
---
Kuninori Morimoto

Re: Question about tsched=0 on PulseAudio

[Takashi Iwai]

On Wed, 17 May 2017 08:24:09 +0200,
Kuninori Morimoto wrote:
> 
> 
> Hi ALSA ML
> 
> We noticed that our PulseAudio has crackling / skipping noise
> which doesn't happen on normal aplay.
> And it was removed if we do below
> 
> 	load-module module-hal-detect tsched=0
> 
> According to google, it say
> 
> 	tsched Since 0.9.11. Use system-timer based model (aka glitch-free).
> 	Defaults to 1 (enabled). If your hardware does not return accurate timing
> 	information (e.g. Creative sound cards) you can try to set tsched=0 to
> 	enable the interupt based timing which was used in 0.9.10 and before.
> 
> Here, what does this "return accurate timing information" mean ?
> Is it struct snd_pcm_ops::pointer ??

Yes.  Also runtime->delay is taken into account.

Both information have to be accurate enough.  With tsched=1, the
period update is basically ignored and PA tries to update the buffer
at its own timing.  The samples to be updated are determined by avail
and delay values of snd_pcm_status, which are calculated from hw_ptr,
appl_ptr and delay in the kernel.

Also, such a problem might be some memory coherency issue.


Takashi

Re: Question about tsched=0 on PulseAudio

[Kuninori Morimoto]

Hi Takashi-san

> > We noticed that our PulseAudio has crackling / skipping noise
> > which doesn't happen on normal aplay.
> > And it was removed if we do below
> > 
> > 	load-module module-hal-detect tsched=0
> > 
> > According to google, it say
> > 
> > 	tsched Since 0.9.11. Use system-timer based model (aka glitch-free).
> > 	Defaults to 1 (enabled). If your hardware does not return accurate timing
> > 	information (e.g. Creative sound cards) you can try to set tsched=0 to
> > 	enable the interupt based timing which was used in 0.9.10 and before.
> > 
> > Here, what does this "return accurate timing information" mean ?
> > Is it struct snd_pcm_ops::pointer ??
> 
> Yes.  Also runtime->delay is taken into account.
> 
> Both information have to be accurate enough.  With tsched=1, the
> period update is basically ignored and PA tries to update the buffer
> at its own timing.  The samples to be updated are determined by avail
> and delay values of snd_pcm_status, which are calculated from hw_ptr,
> appl_ptr and delay in the kernel.
> 
> Also, such a problem might be some memory coherency issue.

OK, thank you for your explanation.
My current driver updates snd_pcm_ops::pointer only when DMA transfer was
finished, but I guess it needs to adjust to update it during transfer, too.
I think I can use dmaengine_tx_status() for this purpose.
I don't know how to know about delay, but I will try update pointer as 1st step.

Best regards
---
Kuninori Morimoto

Re: Question about tsched=0 on PulseAudio

[Takashi Sakamoto]

Hi,

On May 18 2017 14:12, Kuninori Morimoto wrote:
>> Both information have to be accurate enough.  With tsched=1, the
>> period update is basically ignored and PA tries to update the buffer
>> at its own timing.  The samples to be updated are determined by avail
>> and delay values of snd_pcm_status, which are calculated from hw_ptr,
>> appl_ptr and delay in the kernel.
>>
>> Also, such a problem might be some memory coherency issue.
> 
> OK, thank you for your explanation.
> My current driver updates snd_pcm_ops::pointer only when DMA transfer was
> finished, but I guess it needs to adjust to update it during transfer, too.
> I think I can use dmaengine_tx_status() for this purpose.
> I don't know how to know about delay, but I will try update pointer as 1st step.

If your driver calls 'snd_pcm_period_elapsed()' in any hw/sw IRQ 
context, it's correct. But 'struct snd_pcm_ops.pointer' callback is not 
only executed by the function, but also in the other contexts such as 
ioctl(2) with HWSYNC.

In design of ALSA PCM core, the callback is expected to return the 
number of PCM frames currently transferred via physical audio serial 
bus, inner PCM period boundary. As long as I know, recent hardwares have 
any register for this purpose and your driver could calculate the number.

The 'accuracy' represents how accurate the returned number is, against 
actual transferring via audio serial bus.


Regards

Takashi Sakamoto

Re: Question about tsched=0 on PulseAudio

[Kuninori Morimoto]

Hi Takashi-san

# Oops !?
# You and Iwai-san are both same name :)

> > OK, thank you for your explanation.
> > My current driver updates snd_pcm_ops::pointer only when DMA transfer was
> > finished, but I guess it needs to adjust to update it during transfer, too.
> > I think I can use dmaengine_tx_status() for this purpose.
> > I don't know how to know about delay, but I will try update pointer as 1st step.
> 
> If your driver calls 'snd_pcm_period_elapsed()' in any hw/sw IRQ
> context, it's correct. But 'struct snd_pcm_ops.pointer' callback is
> not only executed by the function, but also in the other contexts such
> as ioctl(2) with HWSYNC.
> 
> In design of ALSA PCM core, the callback is expected to return the
> number of PCM frames currently transferred via physical audio serial
> bus, inner PCM period boundary. As long as I know, recent hardwares
> have any register for this purpose and your driver could calculate the
> number.
> 
> The 'accuracy' represents how accurate the returned number is, against
> actual transferring via audio serial bus.

Thank you for your detail explanation.
I will adjust my driver

Best regards
---
Kuninori Morimoto