linux-kernel - Re: Handling xruns in OSS (was re:whatever)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 26 Jun 2007 11:18:12 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Hannu Savolainen <hannu@...nsound.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Handling xruns in OSS (was re:whatever)

At Mon, 25 Jun 2007 23:09:21 +0300,
Hannu Savolainen wrote:
> 
> Takashi Iwai kirjoitti:
> > At Mon, 25 Jun 2007 10:06:18 +0100,
> > Alan Cox wrote:
> >   
> >>> If it is native ALSA driver then it will restart after each underrun
> >>> and overrun. It is the applications job to do this, alsa-lib provides
> >>> all support for this. I have no idea of OSS and OSS emulation in ALSA.
> >>>       
> >> OSS should autorestart on underrun and just moan about overruns and drop
> >> bits. So if it's not following that behaviour he is IMHO correct for the
> >> OSS emulation case.
> >>     
> >
> > I think he is right in the case of read (although I don't remember his
> > post as my buffer overran).  The playback is automaically reset and
> > restarted at underrun.
> >
> > But, the patch there is wrong.  It should handle -EPIPE, which means
> > XRUN, while -ESTRPIPE means the suspend state.
> >   
> To be exact the OSS should not even stop the device when a xrun occurs. 
> Instead it should keep playing silence until the application writes more 
> output data and to discard the oldest recorded data when an overrun 
> occurs. This is more effective than stopping and restarting the device.

Ah, thanks for the hint!

BTW, in this case, how the fragment is aligned to the newly given
samples?  Since the stream is running, and apps may feed the new
samples at any time.  Especially when it uses a small double-buffer
(two short fragments), the wake-up timing is tight, and may introduce
another underrun soon again.


Takashi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/