$ uname -s -r -m
Linux 4.14.175 x86_64
$ cat ${HOME}/.config/mpv/mpv.conf
ao=oss
vo=opengl
audio-channels=stereo
no-msg-color
$ mpv track18.mp3
Playing: track18.mp3
(+) Audio --aid=1 (mp3)
[ao/oss] Can't set audio device to s16 output.
[ao/oss] Can't set audio device to u8 output.
[ao/oss] Can't set sample format.
[ao] Failed to initialize audio driver 'oss'
Could not open/initialize audio device -> no sound.
Audio: no audio
Reverting "ALSA: pcm: oss: Avoid plugin buffer overflow"
upstream commit f2ecf903ef06eb1bbbfa969db9889643d487e73a
restored audio back to normal working state.
--
Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
On Thu, Apr 02, 2020 at 09:06:59PM +0300, Jari Ruusu wrote:
> $ uname -s -r -m
> Linux 4.14.175 x86_64
> $ cat ${HOME}/.config/mpv/mpv.conf
> ao=oss
> vo=opengl
> audio-channels=stereo
> no-msg-color
> $ mpv track18.mp3
> Playing: track18.mp3
> (+) Audio --aid=1 (mp3)
> [ao/oss] Can't set audio device to s16 output.
> [ao/oss] Can't set audio device to u8 output.
> [ao/oss] Can't set sample format.
> [ao] Failed to initialize audio driver 'oss'
> Could not open/initialize audio device -> no sound.
> Audio: no audio
>
>
> Reverting "ALSA: pcm: oss: Avoid plugin buffer overflow"
> upstream commit f2ecf903ef06eb1bbbfa969db9889643d487e73a
> restored audio back to normal working state.
Is this also an issue in 4.19 and 5.4 and Linus's tree?
thanks,
greg k-h
On Thu, 02 Apr 2020 20:06:59 +0200,
Jari Ruusu wrote:
>
> $ uname -s -r -m
> Linux 4.14.175 x86_64
> $ cat ${HOME}/.config/mpv/mpv.conf
> ao=oss
> vo=opengl
> audio-channels=stereo
> no-msg-color
> $ mpv track18.mp3
> Playing: track18.mp3
> (+) Audio --aid=1 (mp3)
> [ao/oss] Can't set audio device to s16 output.
> [ao/oss] Can't set audio device to u8 output.
> [ao/oss] Can't set sample format.
> [ao] Failed to initialize audio driver 'oss'
> Could not open/initialize audio device -> no sound.
> Audio: no audio
>
>
> Reverting "ALSA: pcm: oss: Avoid plugin buffer overflow"
> upstream commit f2ecf903ef06eb1bbbfa969db9889643d487e73a
> restored audio back to normal working state.
Does the patch below change the behavior?
thanks,
Takashi
---
diff --git a/sound/core/oss/pcm_plugin.c b/sound/core/oss/pcm_plugin.c
index 752d078908e9..50c35ecc8953 100644
--- a/sound/core/oss/pcm_plugin.c
+++ b/sound/core/oss/pcm_plugin.c
@@ -196,7 +196,9 @@ int snd_pcm_plugin_free(struct snd_pcm_plugin *plugin)
return 0;
}
-snd_pcm_sframes_t snd_pcm_plug_client_size(struct snd_pcm_substream *plug, snd_pcm_uframes_t drv_frames)
+static snd_pcm_sframes_t plug_client_size(struct snd_pcm_substream *plug,
+ snd_pcm_uframes_t drv_frames,
+ bool check_size)
{
struct snd_pcm_plugin *plugin, *plugin_prev, *plugin_next;
int stream;
@@ -209,7 +211,7 @@ snd_pcm_sframes_t snd_pcm_plug_client_size(struct snd_pcm_substream *plug, snd_p
if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
plugin = snd_pcm_plug_last(plug);
while (plugin && drv_frames > 0) {
- if (drv_frames > plugin->buf_frames)
+ if (check_size && drv_frames > plugin->buf_frames)
drv_frames = plugin->buf_frames;
plugin_prev = plugin->prev;
if (plugin->src_frames)
@@ -222,7 +224,7 @@ snd_pcm_sframes_t snd_pcm_plug_client_size(struct snd_pcm_substream *plug, snd_p
plugin_next = plugin->next;
if (plugin->dst_frames)
drv_frames = plugin->dst_frames(plugin, drv_frames);
- if (drv_frames > plugin->buf_frames)
+ if (check_size && drv_frames > plugin->buf_frames)
drv_frames = plugin->buf_frames;
plugin = plugin_next;
}
@@ -231,7 +233,9 @@ snd_pcm_sframes_t snd_pcm_plug_client_size(struct snd_pcm_substream *plug, snd_p
return drv_frames;
}
-snd_pcm_sframes_t snd_pcm_plug_slave_size(struct snd_pcm_substream *plug, snd_pcm_uframes_t clt_frames)
+static snd_pcm_sframes_t plug_slave_size(struct snd_pcm_substream *plug,
+ snd_pcm_uframes_t clt_frames,
+ bool check_size)
{
struct snd_pcm_plugin *plugin, *plugin_prev, *plugin_next;
snd_pcm_sframes_t frames;
@@ -252,14 +256,14 @@ snd_pcm_sframes_t snd_pcm_plug_slave_size(struct snd_pcm_substream *plug, snd_pc
if (frames < 0)
return frames;
}
- if (frames > plugin->buf_frames)
+ if (check_size && frames > plugin->buf_frames)
frames = plugin->buf_frames;
plugin = plugin_next;
}
} else if (stream == SNDRV_PCM_STREAM_CAPTURE) {
plugin = snd_pcm_plug_last(plug);
while (plugin) {
- if (frames > plugin->buf_frames)
+ if (check_size && frames > plugin->buf_frames)
frames = plugin->buf_frames;
plugin_prev = plugin->prev;
if (plugin->src_frames) {
@@ -274,6 +278,18 @@ snd_pcm_sframes_t snd_pcm_plug_slave_size(struct snd_pcm_substream *plug, snd_pc
return frames;
}
+snd_pcm_sframes_t snd_pcm_plug_client_size(struct snd_pcm_substream *plug,
+ snd_pcm_uframes_t drv_frames)
+{
+ return plug_client_size(plug, drv_frames, false);
+}
+
+snd_pcm_sframes_t snd_pcm_plug_slave_size(struct snd_pcm_substream *plug,
+ snd_pcm_uframes_t clt_frames)
+{
+ return plug_slave_size(plug, clt_frames, false);
+}
+
static int snd_pcm_plug_formats(const struct snd_mask *mask,
snd_pcm_format_t format)
{
@@ -630,7 +646,7 @@ snd_pcm_sframes_t snd_pcm_plug_write_transfer(struct snd_pcm_substream *plug, st
src_channels = dst_channels;
plugin = next;
}
- return snd_pcm_plug_client_size(plug, frames);
+ return plug_client_size(plug, frames, true);
}
snd_pcm_sframes_t snd_pcm_plug_read_transfer(struct snd_pcm_substream *plug, struct snd_pcm_plugin_channel *dst_channels_final, snd_pcm_uframes_t size)
@@ -640,7 +656,7 @@ snd_pcm_sframes_t snd_pcm_plug_read_transfer(struct snd_pcm_substream *plug, str
snd_pcm_sframes_t frames = size;
int err;
- frames = snd_pcm_plug_slave_size(plug, frames);
+ frames = plug_slave_size(plug, frames, true);
if (frames < 0)
return frames;
On Thu, Apr 02, 2020 at 11:24:05PM +0300, Jari Ruusu wrote:
> On 4/2/20, Takashi Iwai <[email protected]> wrote:
> > Does the patch below change the behavior?
>
> Yes, it fixes the problem. No issues observed so far.
> Thank you for your quick fix.
>
> Tested-by: Jari Ruusu <[email protected]>
Is this something that is only needed for 4.14.y, or is it relevant for
Linus's tree as well?
On 4/2/20, Takashi Iwai <[email protected]> wrote:
> Does the patch below change the behavior?
Yes, it fixes the problem. No issues observed so far.
Thank you for your quick fix.
Tested-by: Jari Ruusu <[email protected]>
--
Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
On Thu, 02 Apr 2020 22:29:10 +0200,
Greg Kroah-Hartman wrote:
>
> On Thu, Apr 02, 2020 at 11:24:05PM +0300, Jari Ruusu wrote:
> > On 4/2/20, Takashi Iwai <[email protected]> wrote:
> > > Does the patch below change the behavior?
> >
> > Yes, it fixes the problem. No issues observed so far.
> > Thank you for your quick fix.
> >
> > Tested-by: Jari Ruusu <[email protected]>
>
> Is this something that is only needed for 4.14.y, or is it relevant for
> Linus's tree as well?
It should be applied to Linus tree, too.
I'm going to cook and submit/merge through sound tree.
thanks,
Takashi