'Twas brillig, and David Henningsson at 14/09/10 07:28 did gyre and gimble:
>> Perhaps the problem is that /bin/sh is not actually bash on your system?
>
> It is "dash" on Ubuntu systems.
Yeah I think I remember someone saying that before which is what made me
think of this as the problem :)
>>
On 2010-09-13 13:03, Colin Guthrie wrote:
'Twas brillig, and David Henningsson at 13/09/10 11:14 did gyre and gimble:
On 2010-09-04 14:10, Colin Guthrie wrote:
I'd be interested as to whether anyone else can repeat this experiment
and get similar results. Do you guys get a broken chordtest too
'Twas brillig, and David Henningsson at 13/09/10 11:14 did gyre and gimble:
> On 2010-09-04 14:10, Colin Guthrie wrote:
>> 'Twas brillig, and David Henningsson at 03/09/10 09:46 did gyre and
>> gimble:
>>> 2010-09-02 16:06, pl bossart skrev:
> Agreed: You can pick those two patches, and then we
On 2010-09-04 14:10, Colin Guthrie wrote:
'Twas brillig, and David Henningsson at 03/09/10 09:46 did gyre and gimble:
2010-09-02 16:06, pl bossart skrev:
Agreed: You can pick those two patches, and then we add a third patch to
both branches, which brings back the watermark for tsched devices an
On 2010-09-08 02:52, pl bossart wrote:
So what does this test mean? pavucontrol obviously affects the latency
of the sink due to it's VI meters. This obviously increases the
likelihood of a rewind being triggered.So, with this in mind what
values do you suggest we pick?
Pierre, is it your under
>> So what does this test mean? pavucontrol obviously affects the latency
>> of the sink due to it's VI meters. This obviously increases the
>> likelihood of a rewind being triggered.So, with this in mind what
>> values do you suggest we pick?
>
> Pierre, is it your understanding that it is when DM
On 2010-09-04 14:10, Colin Guthrie wrote:
'Twas brillig, and David Henningsson at 03/09/10 09:46 did gyre and gimble:
2010-09-02 16:06, pl bossart skrev:
Agreed: You can pick those two patches, and then we add a third patch to
both branches, which brings back the watermark for tsched devices an
'Twas brillig, and David Henningsson at 03/09/10 09:46 did gyre and gimble:
> 2010-09-02 16:06, pl bossart skrev:
>>> Agreed: You can pick those two patches, and then we add a third patch to
>>> both branches, which brings back the watermark for tsched devices and 20
>>> ms for non-tsched. Assuming
2010-09-02 16:06, pl bossart skrev:
>> Agreed: You can pick those two patches, and then we add a third patch to
>> both branches, which brings back the watermark for tsched devices and 20
>> ms for non-tsched. Assuming my suspicion is not disproved, of course.
>> What does Pierre think of that?
>
> Agreed: You can pick those two patches, and then we add a third patch to
> both branches, which brings back the watermark for tsched devices and 20
> ms for non-tsched. Assuming my suspicion is not disproved, of course.
> What does Pierre think of that?
I don't want the watermark to be used for
2010-09-02 10:41, Colin Guthrie skrev:
> 'Twas brillig, and David Henningsson at 02/09/10 07:29 did gyre and gimble:
>> 2010-09-01 20:06, pl bossart skrev:
> Probably either one will work, but if we're about to release 0.9.22
> (heard something from Lennart yet?), I suggest we go with my ve
'Twas brillig, and David Henningsson at 02/09/10 07:29 did gyre and gimble:
> 2010-09-01 20:06, pl bossart skrev:
Probably either one will work, but if we're about to release 0.9.22
(heard something from Lennart yet?), I suggest we go with my version for
0.9.22 as that one is the lea
2010-09-01 20:06, pl bossart skrev:
>>> Probably either one will work, but if we're about to release 0.9.22
>>> (heard something from Lennart yet?), I suggest we go with my version for
>>> 0.9.22 as that one is the least invasive (only touches non-tsched
>>> devices), and keep Pierre's version in m
>> Probably either one will work, but if we're about to release 0.9.22
>> (heard something from Lennart yet?), I suggest we go with my version for
>> 0.9.22 as that one is the least invasive (only touches non-tsched
>> devices), and keep Pierre's version in master.
>
> Sounds reasonable. Pierre, wh
'Twas brillig, and Tomasz Torcz at 01/09/10 09:17 did gyre and gimble:
> On Wed, Sep 01, 2010 at 08:39:39AM +0100, Colin Guthrie wrote:
What is the next stage here?
>>>
>>> Probably either one will work, but if we're about to release 0.9.22
>>> (heard something from Lennart yet?), I suggest we
On Wed, Sep 01, 2010 at 08:39:39AM +0100, Colin Guthrie wrote:
> >> What is the next stage here?
> >
> > Probably either one will work, but if we're about to release 0.9.22
> > (heard something from Lennart yet?), I suggest we go with my version for
> > 0.9.22 as that one is the least invasive (on
'Twas brillig, and David Henningsson at 01/09/10 08:36 did gyre and gimble:
> On 2010-08-31 17:57, Colin Guthrie wrote:
>> 'Twas brillig, and pl bossart at 19/08/10 14:52 did gyre and gimble:
> Assuming your reasoning is correct (I'm not that deep into DMA yet),
> this should be fixed in th
On 2010-08-31 17:57, Colin Guthrie wrote:
'Twas brillig, and pl bossart at 19/08/10 14:52 did gyre and gimble:
Assuming your reasoning is correct (I'm not that deep into DMA yet),
this should be fixed in the kernel - by not allowing rewinds further
back than 128 (or 256) bytes ahead of actual po
'Twas brillig, and pl bossart at 19/08/10 14:52 did gyre and gimble:
>>> Assuming your reasoning is correct (I'm not that deep into DMA yet),
>>> this should be fixed in the kernel - by not allowing rewinds further
>>> back than 128 (or 256) bytes ahead of actual position.
>>> You say HDA can trans
2010-08-19 07:32, Tanu Kaskinen skrev:
> On Wed, 2010-08-18 at 22:55 +0200, David Henningsson wrote:
>>> Yes the safeguard is needed in both cases, timer scheduling or good
>>> ol' audio interrupts. This comes from limitations of the
>>> snd_pcm_rewind() routine, you can rewind the appl_ptr all the
>> Assuming your reasoning is correct (I'm not that deep into DMA yet),
>> this should be fixed in the kernel - by not allowing rewinds further
>> back than 128 (or 256) bytes ahead of actual position.
>> You say HDA can transfer up to 128 bytes in advance, but what about all
>> the other drivers?
'Twas brillig, and Tanu Kaskinen at 19/08/10 06:32 did gyre and gimble:
> IIRC
> pavucontrol ratelimits the volume change events to minimum of 100ms
> between each event sent to the daemon - that's still ten times a
> second
I think it actually waits for the sound event to stop playing rather
than
On Wed, 2010-08-18 at 22:55 +0200, David Henningsson wrote:
> > Yes the safeguard is needed in both cases, timer scheduling or good
> > ol' audio interrupts. This comes from limitations of the
> > snd_pcm_rewind() routine, you can rewind the appl_ptr all the way to
> > the hardware pointer, but you
2010-08-18 19:19, pl bossart skrev:
>>> * Pierre-Louis Bossart's version in git master sets a fixed margin of
>>> 256 bytes, (configurable if you load the sink manually, i e not through
>>> module-udev-detect).
>>>
>>> * My version sets a fixed margin of 20 ms.
>>>
>>> * My version only changes non
>> * Pierre-Louis Bossart's version in git master sets a fixed margin of
>> 256 bytes, (configurable if you load the sink manually, i e not through
>> module-udev-detect).
>>
>> * My version sets a fixed margin of 20 ms.
>>
>> * My version only changes non-tsched devices and keeps tsched having a
>
'Twas brillig, and David Henningsson at 18/08/10 09:28 did gyre and gimble:
> 2010-08-17 21:10, Colin Guthrie skrev:
>> 'Twas brillig, and David Henningsson at 17/08/10 19:20 did gyre and gimble:
>>> According to what you say in that bug, you could reproduce it yourself
>>> by setting tsched=0, so
2010-08-17 21:10, Colin Guthrie skrev:
> 'Twas brillig, and David Henningsson at 17/08/10 19:20 did gyre and gimble:
>> According to what you say in that bug, you could reproduce it yourself
>> by setting tsched=0, so I'm eager to hear if this fix fixes your issue
>> as well.
>
> Yeah I was able t
'Twas brillig, and David Henningsson at 17/08/10 19:20 did gyre and gimble:
> According to what you say in that bug, you could reproduce it yourself
> by setting tsched=0, so I'm eager to hear if this fix fixes your issue
> as well.
Yeah I was able to reproduce it pretty easily with the chordtest.
2010-08-17 20:03, Colin Guthrie skrev:
> 'Twas brillig, and David Henningsson at 17/08/10 19:00 did gyre and gimble:
>> The tsched watermark variable was incorrectly used even for sinks
>> with timer scheduling disabled, causing XRUNs on every rewind. This
>> patch sets a fixed margin of 20 msec fo
'Twas brillig, and Colin Guthrie at 17/08/10 19:03 did gyre and gimble:
> 'Twas brillig, and David Henningsson at 17/08/10 19:00 did gyre and gimble:
>> The tsched watermark variable was incorrectly used even for sinks
>> with timer scheduling disabled, causing XRUNs on every rewind. This
>> patch
'Twas brillig, and David Henningsson at 17/08/10 19:00 did gyre and gimble:
> The tsched watermark variable was incorrectly used even for sinks
> with timer scheduling disabled, causing XRUNs on every rewind. This
> patch sets a fixed margin of 20 msec for such rewinds, thus avoiding
> the underrun
The tsched watermark variable was incorrectly used even for sinks
with timer scheduling disabled, causing XRUNs on every rewind. This
patch sets a fixed margin of 20 msec for such rewinds, thus avoiding
the underrun.
One could argue that the margin should be adjustable somehow (or based
on fragmen
32 matches
Mail list logo
