From: Mark Hills <mark@xwax.org>
To: Giuliano Pochini <pochini@shiny.it>
Cc: Takashi Iwai <tiwai@suse.de>, alsa-devel@alsa-project.org
Subject: Re: [PATCH 3/3] echoaudio: Address bugs in the interrupt handling
Date: Wed, 1 Jul 2020 13:25:07 +0100 (BST) [thread overview]
Message-ID: <2007011320590.17595@stax.localdomain> (raw)
In-Reply-To: <20200629000139.0212fa11@wc1>
On Mon, 29 Jun 2020, Giuliano Pochini wrote:
> On Fri, 19 Jun 2020 22:21:54 +0100 (BST)
> Mark Hills <mark@xwax.org> wrote:
>
> > On Fri, 19 Jun 2020, Giuliano Pochini wrote:
> >
> > > On Wed, 17 Jun 2020 12:14:42 +0100 (BST)
> > > Mark Hills <mark@xwax.org> wrote:
> > >
> > [...]
> > > > You might be able to do the comparison before wrapping pipe_position,
> > > > but hopefully you'll consider my patch in reply to Takashi has more
> > > > clarity.
> > >
> > > Your patch is very interesting. I didn't take into account the idea of
> > > advancing the position by full periods only. If the PCM subsystem
> > > hasn't changed much since I last checked (I wrote the driver many years
> > > ago), it should work fine (and I'm sure you tested it). But I don't
> > > know if something else requires better resolution.
> >
> > It's funny, but I didn't take account of the opposite; that there was any
> > merits to polling inbetween the interrupts for better resolution.
> >
> > Takashi pointed out the need for this and we had some discussion. Check
> > the other thread, where I provided a newer revision of the code.
> >
> > The good thing is I think we can have all the things we want and be bug
> > free, just I have to understand the specification.
> >
> > It would be great if you would like to take a look at the newer code for
> > any problems you can see. I was going to run it for a few days then turn
> > it into some patches.
>
> I looked at your code and I think it's OK. I'm using it for some days
> without any problem. I also stressed it with pretty tight timings and it
> worked fine all the time.
>
> Since I could not reproduce that problem before, except in some rare
> random circumstances, I'm not a good tester at all. At most I can say
> that your patch does not make things worse :)
What software are you using on the device, and are you using x86_64 and
dmix?
I think some issues might be exaggerated by dmix which has a unique way of
opening the device several times. And then chromium exercises dmix a lot
with all of its threads/forks. That would I presume be how it exercises
races between pcm_pointer and interrupts.
--
Mark
next prev parent reply other threads:[~2020-07-01 12:26 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-16 13:13 echoaudio: Fix some long standing bugs Mark Hills
2020-06-16 13:17 ` [PATCH 1/3] echoaudio: Race conditions around "opencount" Mark Hills
2020-06-16 13:17 ` [PATCH 2/3] echoaudio: Prevent races in calls to set_audio_format() Mark Hills
2020-06-16 13:24 ` Takashi Iwai
2020-06-16 13:17 ` [PATCH 3/3] echoaudio: Address bugs in the interrupt handling Mark Hills
2020-06-16 13:35 ` Takashi Iwai
2020-06-16 14:01 ` Mark Hills
2020-06-16 14:18 ` Takashi Iwai
2020-06-17 10:51 ` Mark Hills
2020-06-18 8:17 ` Takashi Iwai
2020-06-18 11:07 ` Mark Hills
2020-06-18 11:21 ` Takashi Iwai
2020-06-18 12:29 ` Mark Hills
2020-06-18 13:22 ` Mark Hills
2020-06-16 19:46 ` Giuliano Pochini
2020-06-17 10:57 ` Mark Hills
2020-06-16 22:01 ` Giuliano Pochini
2020-06-17 11:14 ` Mark Hills
2020-06-19 19:56 ` Giuliano Pochini
2020-06-19 21:21 ` Mark Hills
2020-06-28 22:02 ` Giuliano Pochini
2020-07-01 12:25 ` Mark Hills [this message]
2020-07-01 14:51 ` Giuliano Pochini
2020-07-01 12:25 ` echoaudio: Fix some long standing bugs Mark Hills
2020-07-01 12:27 ` [PATCH 1/4] echoaudio: Race conditions around "opencount" Mark Hills
2020-07-01 16:37 ` kernel test robot
2020-07-01 17:32 ` kernel test robot
2020-07-02 9:53 ` Mark Hills
2020-07-07 8:28 ` Takashi Iwai
2020-07-08 10:16 ` Mark Hills
2020-07-08 10:18 ` [PATCH 1/5] echoaudio: Remove redundant check Mark Hills
2020-07-09 11:00 ` Takashi Iwai
2020-07-08 10:18 ` [PATCH 2/5] echoaudio: Race conditions around "opencount" Mark Hills
2020-07-09 11:00 ` Takashi Iwai
2020-07-08 10:18 ` [PATCH 3/5] echoaudio: Prevent races in calls to set_audio_format() Mark Hills
2020-07-09 11:00 ` Takashi Iwai
2020-07-08 10:18 ` [PATCH 4/5] echoaudio: Prevent some noise on unloading the module Mark Hills
2020-07-09 11:00 ` Takashi Iwai
2020-07-08 10:18 ` [PATCH 5/5] echoaudio: Address bugs in the interrupt handling Mark Hills
2020-07-09 11:01 ` Takashi Iwai
2020-07-01 12:27 ` [PATCH 2/4] echoaudio: Prevent races in calls to set_audio_format() Mark Hills
2020-07-01 12:27 ` [PATCH 3/4] echoaudio: Prevent some noise on unloading the module Mark Hills
2020-07-01 12:27 ` [PATCH 4/4] echoaudio: Address bugs in the interrupt handling Mark Hills
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=2007011320590.17595@stax.localdomain \
--to=mark@xwax.org \
--cc=alsa-devel@alsa-project.org \
--cc=pochini@shiny.it \
--cc=tiwai@suse.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox