Re: [alsa-devel] [Pkg-alsa-devel] Bug#438118: alsa-utils: aplay non-blocking mode isn't working
forwarded 438118 alsa-devel@alsa-project.org
stop
Hi all,
can one please have a lokk at this? aplay -N isn't working for the OP.
On Thu, 16 Aug 2007 the mental interface of Anders Boström told:
"ER" == Elimar Riesebieter riesebie@lxtec.de writes:
strace aplay -N :
... open("/usr/lib/alsa-lib/libasound_module_rate_speexrate.so", O_RDONLY) = -1 ENOENT (No such file or directory)
ER> This file is provided by ER> libasound2-plugins: /usr/lib/alsa-lib/libasound_module_rate_speexrate.so
ER> Please install libasound2-plugins and try again.
Thanks for the suggestion.
Unfortunately, it didn't solve my problem, no sound when non-blocking mode is used. New strace:
strace aplay -N : ... open("/usr/lib/alsa-lib/libasound_module_rate_speexrate.so", O_RDONLY) = 5 read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\22\0"..., 832) = 832 fstat(5, {st_mode=S_IFREG|0644, st_size=20848, ...}) = 0 mmap(NULL, 2116136, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0x2b9f792fe000 mprotect(0x2b9f79302000, 2097152, PROT_NONE) = 0 mmap(0x2b9f79502000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x4000) = 0x2b9f79502000 close(5) = 0 ioctl(4, 0xc2604110, 0x7fff3269dec0) = 0 ioctl(4, 0xc2604110, 0x7fff3269dec0) = 0 ioctl(4, 0xc2604110, 0x7fff3269de00) = 0 ioctl(4, 0xc2604110, 0x7fff3269de00) = 0 ioctl(4, 0xc2604110, 0x7fff3269ddd0) = 0 ioctl(4, 0xc2604110, 0x7fff3269ddc0) = 0 ioctl(4, 0xc2604111, 0x7fff3269ddc0) = 0 ioctl(4, 0xc0884113, 0x7fff3269dd10) = 0 ioctl(4, 0x80184132, 0x7fff3269dc70) = 0 mmap(NULL, 49152, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0x2b9f79503000 ioctl(4, 0xc0884113, 0x624e88) = 0 ioctl(4, 0x4140, 0) = 0 ioctl(4, 0xc0884113, 0x624e88) = 0 read(3, "\377eO\333\337\370\344}\335_\377\330^l\356\361`j\336_l"..., 1001) = 1001 read(3, "n{u^\342zl~e~_[\365_y\362_\363\350\337n[\347nmi`\367y\344"..., 604) = 604 ioctl(4, 0x4144, 0x2b9f785d8000) = -1 EAGAIN (Resource temporarily unavailable) close(3) = 0 ioctl(4, 0x4143, 0x3) = 0 munmap(0x2b9f79503000, 49152) = 0 ioctl(4, 0x4112, 0) = 0 close(4) = 0 munmap(0x2b9f785d7000, 4096) = 0 munmap(0x2b9f785d8000, 4096) = 0 munmap(0x2b9f792fe000, 2116136) = 0 exit_group(0) = ?
I have no idea, so forwarded to alsa-dev then.
THX in advance
Elimar
At Tue, 11 Sep 2007 18:08:11 +0200, Elimar Riesebieter wrote:
forwarded 438118 alsa-devel@alsa-project.org
stop
Hi all,
can one please have a lokk at this? aplay -N isn't working for the OP.
Cannot reproduce here. Could you _post_ more details?
thanks,
Takashi
On Thu, 16 Aug 2007 the mental interface of Anders Boström told:
> "ER" == Elimar Riesebieter riesebie@lxtec.de writes:
strace aplay -N :
... open("/usr/lib/alsa-lib/libasound_module_rate_speexrate.so", O_RDONLY) = -1 ENOENT (No such file or directory)
ER> This file is provided by ER> libasound2-plugins: /usr/lib/alsa-lib/libasound_module_rate_speexrate.so
ER> Please install libasound2-plugins and try again.
Thanks for the suggestion.
Unfortunately, it didn't solve my problem, no sound when non-blocking mode is used. New strace:
strace aplay -N : ... open("/usr/lib/alsa-lib/libasound_module_rate_speexrate.so", O_RDONLY) = 5 read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\22\0"..., 832) = 832 fstat(5, {st_mode=S_IFREG|0644, st_size=20848, ...}) = 0 mmap(NULL, 2116136, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0x2b9f792fe000 mprotect(0x2b9f79302000, 2097152, PROT_NONE) = 0 mmap(0x2b9f79502000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x4000) = 0x2b9f79502000 close(5) = 0 ioctl(4, 0xc2604110, 0x7fff3269dec0) = 0 ioctl(4, 0xc2604110, 0x7fff3269dec0) = 0 ioctl(4, 0xc2604110, 0x7fff3269de00) = 0 ioctl(4, 0xc2604110, 0x7fff3269de00) = 0 ioctl(4, 0xc2604110, 0x7fff3269ddd0) = 0 ioctl(4, 0xc2604110, 0x7fff3269ddc0) = 0 ioctl(4, 0xc2604111, 0x7fff3269ddc0) = 0 ioctl(4, 0xc0884113, 0x7fff3269dd10) = 0 ioctl(4, 0x80184132, 0x7fff3269dc70) = 0 mmap(NULL, 49152, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0x2b9f79503000 ioctl(4, 0xc0884113, 0x624e88) = 0 ioctl(4, 0x4140, 0) = 0 ioctl(4, 0xc0884113, 0x624e88) = 0 read(3, "\377eO\333\337\370\344}\335_\377\330^l\356\361`j\336_l"..., 1001) = 1001 read(3, "n{u^\342zl~e~_[\365_y\362_\363\350\337n[\347nmi`\367y\344"..., 604) = 604 ioctl(4, 0x4144, 0x2b9f785d8000) = -1 EAGAIN (Resource temporarily unavailable) close(3) = 0 ioctl(4, 0x4143, 0x3) = 0 munmap(0x2b9f79503000, 49152) = 0 ioctl(4, 0x4112, 0) = 0 close(4) = 0 munmap(0x2b9f785d7000, 4096) = 0 munmap(0x2b9f785d8000, 4096) = 0 munmap(0x2b9f792fe000, 2116136) = 0 exit_group(0) = ?
I have no idea, so forwarded to alsa-dev then.
THX in advance
Elimar
-- Experience is something you don't get until just after you need it!
"TI" == Takashi Iwai tiwai@suse.de writes:
Hi!
Hi all,
can one please have a lokk at this? aplay -N isn't working for the OP.
TI> Cannot reproduce here. Could you _post_ more details?
OK, I've tested more, and discovered that the problem seems to be that the end of the sound is cut in non-blocking mode. And if I play a very short sound-file, I can't hear anything. Blocking mode works fine.
When using non-blocking mode, an strace contains "ioctl(4, 0x4144, 0x2b9f785d8000) = -1 EAGAIN (Resource temporarily unavailable)". Blocking mode never contains the EAGAIN response.
I attach two files. When playing halt.au, I can only hear the start, about as much as "ha". When playing metal.au, I can't hear anything.
System info:
ASUS A8V Deluxe motherboard with Athlon 64 3500+ CPU VIA 8237 with ALC850 sound Linux 2.6.22.2 kernel for amd64 Debian testing amd64 with: alsa-utils 1.0.14-1 libasound2 1.0.14a-2 libc6 2.6.1-1
I hope this helps. Please ask if you need more info.
/ Anders
On Thu, 16 Aug 2007 the mental interface of Anders Boström told:
>> "ER" == Elimar Riesebieter riesebie@lxtec.de writes:
strace aplay -N :
... open("/usr/lib/alsa-lib/libasound_module_rate_speexrate.so", O_RDONLY) = -1 ENOENT (No such file or directory)
ER> This file is provided by ER> libasound2-plugins: /usr/lib/alsa-lib/libasound_module_rate_speexrate.so
ER> Please install libasound2-plugins and try again.
Thanks for the suggestion.
Unfortunately, it didn't solve my problem, no sound when non-blocking mode is used. New strace:
strace aplay -N : ... open("/usr/lib/alsa-lib/libasound_module_rate_speexrate.so", O_RDONLY) = 5 read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\22\0"..., 832) = 832 fstat(5, {st_mode=S_IFREG|0644, st_size=20848, ...}) = 0 mmap(NULL, 2116136, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0x2b9f792fe000 mprotect(0x2b9f79302000, 2097152, PROT_NONE) = 0 mmap(0x2b9f79502000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x4000) = 0x2b9f79502000 close(5) = 0 ioctl(4, 0xc2604110, 0x7fff3269dec0) = 0 ioctl(4, 0xc2604110, 0x7fff3269dec0) = 0 ioctl(4, 0xc2604110, 0x7fff3269de00) = 0 ioctl(4, 0xc2604110, 0x7fff3269de00) = 0 ioctl(4, 0xc2604110, 0x7fff3269ddd0) = 0 ioctl(4, 0xc2604110, 0x7fff3269ddc0) = 0 ioctl(4, 0xc2604111, 0x7fff3269ddc0) = 0 ioctl(4, 0xc0884113, 0x7fff3269dd10) = 0 ioctl(4, 0x80184132, 0x7fff3269dc70) = 0 mmap(NULL, 49152, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0x2b9f79503000 ioctl(4, 0xc0884113, 0x624e88) = 0 ioctl(4, 0x4140, 0) = 0 ioctl(4, 0xc0884113, 0x624e88) = 0 read(3, "\377eO\333\337\370\344}\335_\377\330^l\356\361`j\336_l"..., 1001) = 1001 read(3, "n{u^\342zl~e~_[\365_y\362_\363\350\337n[\347nmi`\367y\344"..., 604) = 604 ioctl(4, 0x4144, 0x2b9f785d8000) = -1 EAGAIN (Resource temporarily unavailable) close(3) = 0 ioctl(4, 0x4143, 0x3) = 0 munmap(0x2b9f79503000, 49152) = 0 ioctl(4, 0x4112, 0) = 0 close(4) = 0 munmap(0x2b9f785d7000, 4096) = 0 munmap(0x2b9f785d8000, 4096) = 0 munmap(0x2b9f792fe000, 2116136) = 0 exit_group(0) = ?
I have no idea, so forwarded to alsa-dev then.
THX in advance
Elimar
-- Experience is something you don't get until just after you need it!
At Tue, 18 Sep 2007 09:41:48 +0200 (CEST), Anders Boström wrote:
"TI" == Takashi Iwai tiwai@suse.de writes:
Hi!
Hi all,
can one please have a lokk at this? aplay -N isn't working for the OP.
TI> Cannot reproduce here. Could you _post_ more details?
OK, I've tested more, and discovered that the problem seems to be that the end of the sound is cut in non-blocking mode. And if I play a very short sound-file, I can't hear anything. Blocking mode works fine.
When using non-blocking mode, an strace contains "ioctl(4, 0x4144, 0x2b9f785d8000) = -1 EAGAIN (Resource temporarily unavailable)". Blocking mode never contains the EAGAIN response.
I attach two files. When playing halt.au, I can only hear the start, about as much as "ha". When playing metal.au, I can't hear anything.
OK, thanks, I see the problem now.
I don't remember whether it's a feature or a bug. The drain ioctl rejects the non-block mode.
Anyway, a simple patch is below. Let me know if it works.
Takashi
diff -r 0028e39ead78 core/pcm_native.c --- a/core/pcm_native.c Tue Sep 18 00:52:38 2007 +0200 +++ b/core/pcm_native.c Tue Sep 18 17:44:31 2007 +0200 @@ -1368,8 +1368,6 @@ static int snd_pcm_prepare(struct snd_pc
static int snd_pcm_pre_drain_init(struct snd_pcm_substream *substream, int state) { - if (substream->f_flags & O_NONBLOCK) - return -EAGAIN; substream->runtime->trigger_master = substream; return 0; }
"TI" == Takashi Iwai tiwai@suse.de writes:
TI> At Tue, 18 Sep 2007 09:41:48 +0200 (CEST), TI> Anders Boström wrote:
> "TI" == Takashi Iwai tiwai@suse.de writes:
can one please have a lokk at this? aplay -N isn't working for the OP.
TI> Cannot reproduce here. Could you _post_ more details?
OK, I've tested more, and discovered that the problem seems to be that the end of the sound is cut in non-blocking mode. And if I play a very short sound-file, I can't hear anything. Blocking mode works fine.
When using non-blocking mode, an strace contains "ioctl(4, 0x4144, 0x2b9f785d8000) = -1 EAGAIN (Resource temporarily unavailable)". Blocking mode never contains the EAGAIN response.
I attach two files. When playing halt.au, I can only hear the start, about as much as "ha". When playing metal.au, I can't hear anything.
TI> OK, thanks, I see the problem now.
TI> I don't remember whether it's a feature or a bug. The drain ioctl TI> rejects the non-block mode.
I can understand the idea here, that in non-blocking mode, no call should block, ever. But on the other hand, if you call the drain ioctl, you probably expect it to work, even in non-blocking mode. Why would you otherwise call it?
TI> Anyway, a simple patch is below. Let me know if it works.
It works fine! Thanks!
/ Anders
TI> diff -r 0028e39ead78 core/pcm_native.c TI> --- a/core/pcm_native.c Tue Sep 18 00:52:38 2007 +0200 TI> +++ b/core/pcm_native.c Tue Sep 18 17:44:31 2007 +0200 TI> @@ -1368,8 +1368,6 @@ static int snd_pcm_prepare(struct snd_pc
TI> static int snd_pcm_pre_drain_init(struct snd_pcm_substream *substream, int state) TI> { TI> - if (substream->f_flags & O_NONBLOCK) TI> - return -EAGAIN; substream-> runtime->trigger_master = substream; TI> return 0; TI> }
At Thu, 27 Sep 2007 14:16:29 +0200 (CEST), Anders Boström wrote:
"TI" == Takashi Iwai tiwai@suse.de writes:
TI> At Tue, 18 Sep 2007 09:41:48 +0200 (CEST), TI> Anders Boström wrote:
>> "TI" == Takashi Iwai tiwai@suse.de writes:
can one please have a lokk at this? aplay -N isn't working for the OP.
TI> Cannot reproduce here. Could you _post_ more details?
OK, I've tested more, and discovered that the problem seems to be that the end of the sound is cut in non-blocking mode. And if I play a very short sound-file, I can't hear anything. Blocking mode works fine.
When using non-blocking mode, an strace contains "ioctl(4, 0x4144, 0x2b9f785d8000) = -1 EAGAIN (Resource temporarily unavailable)". Blocking mode never contains the EAGAIN response.
I attach two files. When playing halt.au, I can only hear the start, about as much as "ha". When playing metal.au, I can't hear anything.
TI> OK, thanks, I see the problem now.
TI> I don't remember whether it's a feature or a bug. The drain ioctl TI> rejects the non-block mode.
I can understand the idea here, that in non-blocking mode, no call should block, ever. But on the other hand, if you call the drain ioctl, you probably expect it to work, even in non-blocking mode. Why would you otherwise call it?
Yes, that's my opinion, too. This particular ioctl is to block the operation, so it should be allowed as long as it's called.
But I vaguely remember that we discussed about it, and the current form is the result of that. Namely, we can call snd_pcm_nonblock(FALSE) explicitly before calling snd_pcm_drain().
Though, I prefer fixing the behavior in the core side to allow the blocking with this call... Any reasonable objections in mind?
Takashi
"TI" == Takashi Iwai tiwai@suse.de writes:
TI> OK, thanks, I see the problem now.
TI> I don't remember whether it's a feature or a bug. The drain ioctl TI> rejects the non-block mode.
I can understand the idea here, that in non-blocking mode, no call should block, ever. But on the other hand, if you call the drain ioctl, you probably expect it to work, even in non-blocking mode. Why would you otherwise call it?
TI> Yes, that's my opinion, too. This particular ioctl is to block the TI> operation, so it should be allowed as long as it's called.
TI> But I vaguely remember that we discussed about it, and the current TI> form is the result of that. Namely, we can call TI> snd_pcm_nonblock(FALSE) explicitly before calling snd_pcm_drain().
TI> Though, I prefer fixing the behavior in the core side to allow the TI> blocking with this call... Any reasonable objections in mind?
Any progress in including a solotion to this bug in mainstream alsa & linux kernel? Has anything been done? The patch works fine for me...
/ Anders
On Fri, 14 Dec 2007, Anders Boström wrote:
"TI" == Takashi Iwai tiwai@suse.de writes:
TI> OK, thanks, I see the problem now.
TI> I don't remember whether it's a feature or a bug. The drain ioctl TI> rejects the non-block mode.
I can understand the idea here, that in non-blocking mode, no call should block, ever. But on the other hand, if you call the drain ioctl, you probably expect it to work, even in non-blocking mode. Why would you otherwise call it?
TI> Yes, that's my opinion, too. This particular ioctl is to block the TI> operation, so it should be allowed as long as it's called.
TI> But I vaguely remember that we discussed about it, and the current TI> form is the result of that. Namely, we can call TI> snd_pcm_nonblock(FALSE) explicitly before calling snd_pcm_drain().
TI> Though, I prefer fixing the behavior in the core side to allow the TI> blocking with this call... Any reasonable objections in mind?
Any progress in including a solotion to this bug in mainstream alsa & linux kernel? Has anything been done? The patch works fine for me...
I think that this proposal breaks basic posix rules. Application should change blocking state itself. And non-blocking snd_pcm_drain() still makes sense - it will return state of stream (-EAGAIN - unfinished) or reset PCM state to SETUP in case when all data are played.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project
At Fri, 14 Dec 2007 11:53:11 +0100 (CET), Jaroslav Kysela wrote:
On Fri, 14 Dec 2007, Anders Boström wrote:
> "TI" == Takashi Iwai tiwai@suse.de writes:
TI> OK, thanks, I see the problem now.
TI> I don't remember whether it's a feature or a bug. The drain ioctl TI> rejects the non-block mode.
I can understand the idea here, that in non-blocking mode, no call should block, ever. But on the other hand, if you call the drain ioctl, you probably expect it to work, even in non-blocking mode. Why would you otherwise call it?
TI> Yes, that's my opinion, too. This particular ioctl is to block the TI> operation, so it should be allowed as long as it's called.
TI> But I vaguely remember that we discussed about it, and the current TI> form is the result of that. Namely, we can call TI> snd_pcm_nonblock(FALSE) explicitly before calling snd_pcm_drain().
TI> Though, I prefer fixing the behavior in the core side to allow the TI> blocking with this call... Any reasonable objections in mind?
Any progress in including a solotion to this bug in mainstream alsa & linux kernel? Has anything been done? The patch works fine for me...
I think that this proposal breaks basic posix rules.
AFAIK, O_NONBLOCK doesn't define the behavior of each ioctl on POSIX at all. Some standard POSIX-defined ioctls block even with O_NONBLOCK indeed.
Application should change blocking state itself. And non-blocking snd_pcm_drain() still makes sense - it will return state of stream (-EAGAIN - unfinished) or reset PCM state to SETUP in case when all data are played.
Well, this can be kept as is, but it's a bit weird (and silly) behavior. Anyway, we'll need fix this bug in our own codes in alsa-utils first :)
Takashi
participants (5)
-
Anders Boström -
Anders Boström -
Elimar Riesebieter -
Jaroslav Kysela -
Takashi Iwai