linux-kernel - 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]

Message-ID: <468020F1.1090602@opensound.com>
Date:	Mon, 25 Jun 2007 23:09:21 +0300
From:	Hannu Savolainen <hannu@...nsound.com>
To:	Takashi Iwai <tiwai@...e.de>, linux-kernel@...r.kernel.org
Subject: Handling xruns in OSS (was re:whatever)

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.

Best regards,

Hannu
-
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/