Re: [alsa-devel] Capture not working in MMAP mode with '-v'
-----Original Message----- From: Aggarwal, Anuj Sent: Thursday, September 24, 2009 2:28 PM To: alsa-devel@alsa-project.org Subject: Capture not working in MMAP mode with '-v'
Hi,
When I try to capture audio in MMAP mode using the following command, it works properly:
arecord -f cd -d 10 -M rec01.wav
However, if I specify '-v' along with the above command, it fails to capture anything and prints log and returns immediately:
Recording WAVE 'rec03.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo Plug PCM: Hardware PCM card 0 'omap3evm' device 0 subdevice 0 Its setup is: stream : CAPTURE access : MMAP_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 22052 period_size : 5513 period_time : 125011 tstamp_mode : NONE period_step : 1 avail_min : 5513 period_event : 0 start_threshold : 1 stop_threshold : 22052 silence_threshold: 0 silence_size : 0 boundary : 1445199872 appl_ptr : 0 hw_ptr : 0 mmap_area[0] = 0x4030e000,0,32 (16) mmap_area[1] = 0x4030e000,16,32 (16)
I have not observed this problem while playing audio, only while capture this issue crops up.
Any pointers?
Any updates on this? We have observed similar problem on other platforms as well.
Thanks & Regards, Anuj Aggarwal
On Mon, 2009-11-09 at 08:56 +0100, ext Aggarwal, Anuj wrote:
-----Original Message----- From: Aggarwal, Anuj Sent: Thursday, September 24, 2009 2:28 PM To: alsa-devel@alsa-project.org Subject: Capture not working in MMAP mode with '-v'
Hi,
When I try to capture audio in MMAP mode using the following command, it works properly:
arecord -f cd -d 10 -M rec01.wav
However, if I specify '-v' along with the above command, it fails to capture anything and prints log and returns immediately:
Recording WAVE 'rec03.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo Plug PCM: Hardware PCM card 0 'omap3evm' device 0 subdevice 0 Its setup is: stream : CAPTURE access : MMAP_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 22052 period_size : 5513 period_time : 125011 tstamp_mode : NONE period_step : 1 avail_min : 5513 period_event : 0 start_threshold : 1 stop_threshold : 22052 silence_threshold: 0 silence_size : 0 boundary : 1445199872 appl_ptr : 0 hw_ptr : 0 mmap_area[0] = 0x4030e000,0,32 (16) mmap_area[1] = 0x4030e000,16,32 (16)
I have not observed this problem while playing audio, only while capture this issue crops up.
Any pointers?
Any updates on this? We have observed similar problem on other platforms as well.
Yeah, it's an aplay bug, I've seen it & tracked down to aplay. It actually makes the recording file very huge instantly on some systems. Patch out the aplay when -M and -v are used =)
Thanks & Regards, Anuj Aggarwal
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
-----Original Message----- From: Eero Nurkkala [mailto:ext-eero.nurkkala@nokia.com] Sent: Monday, November 09, 2009 1:28 PM To: Aggarwal, Anuj Cc: alsa-devel@alsa-project.org Subject: Re: [alsa-devel] Capture not working in MMAP mode with '-v'
On Mon, 2009-11-09 at 08:56 +0100, ext Aggarwal, Anuj wrote:
-----Original Message----- From: Aggarwal, Anuj Sent: Thursday, September 24, 2009 2:28 PM To: alsa-devel@alsa-project.org Subject: Capture not working in MMAP mode with '-v'
Hi,
When I try to capture audio in MMAP mode using the following command, it works properly:
arecord -f cd -d 10 -M rec01.wav
However, if I specify '-v' along with the above command, it fails to capture anything and prints log and returns immediately:
Recording WAVE 'rec03.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo Plug PCM: Hardware PCM card 0 'omap3evm' device 0 subdevice 0 Its setup is: stream : CAPTURE access : MMAP_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 22052 period_size : 5513 period_time : 125011 tstamp_mode : NONE period_step : 1 avail_min : 5513 period_event : 0 start_threshold : 1 stop_threshold : 22052 silence_threshold: 0 silence_size : 0 boundary : 1445199872 appl_ptr : 0 hw_ptr : 0 mmap_area[0] = 0x4030e000,0,32 (16) mmap_area[1] = 0x4030e000,16,32 (16)
I have not observed this problem while playing audio, only while capture this issue crops up.
Any pointers?
Any updates on this? We have observed similar problem on other platforms as well.
Yeah, it's an aplay bug, I've seen it & tracked down to aplay. It actually makes the recording file very huge instantly on some systems. Patch out the aplay when -M and -v are used =)
Is there a new version of alsa-utils available which fixes this problem? Also, I have seen this problem only while using arecord, not aplay, though they both point to the same source file? Whats the reason for this?
Thanks & Regards, Anuj Aggarwal
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Mon, 2009-11-09 at 09:05 +0100, ext Aggarwal, Anuj wrote:
-----Original Message----- From: Eero Nurkkala [mailto:ext-eero.nurkkala@nokia.com] Sent: Monday, November 09, 2009 1:28 PM To: Aggarwal, Anuj Cc: alsa-devel@alsa-project.org Subject: Re: [alsa-devel] Capture not working in MMAP mode with '-v'
On Mon, 2009-11-09 at 08:56 +0100, ext Aggarwal, Anuj wrote:
-----Original Message----- From: Aggarwal, Anuj Sent: Thursday, September 24, 2009 2:28 PM To: alsa-devel@alsa-project.org Subject: Capture not working in MMAP mode with '-v'
Hi,
When I try to capture audio in MMAP mode using the following command, it works properly:
arecord -f cd -d 10 -M rec01.wav
However, if I specify '-v' along with the above command, it fails to capture anything and prints log and returns immediately:
Recording WAVE 'rec03.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo Plug PCM: Hardware PCM card 0 'omap3evm' device 0 subdevice 0 Its setup is: stream : CAPTURE access : MMAP_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 22052 period_size : 5513 period_time : 125011 tstamp_mode : NONE period_step : 1 avail_min : 5513 period_event : 0 start_threshold : 1 stop_threshold : 22052 silence_threshold: 0 silence_size : 0 boundary : 1445199872 appl_ptr : 0 hw_ptr : 0 mmap_area[0] = 0x4030e000,0,32 (16) mmap_area[1] = 0x4030e000,16,32 (16)
I have not observed this problem while playing audio, only while capture this issue crops up.
Any pointers?
Any updates on this? We have observed similar problem on other platforms as well.
Yeah, it's an aplay bug, I've seen it & tracked down to aplay. It actually makes the recording file very huge instantly on some systems. Patch out the aplay when -M and -v are used =)
Is there a new version of alsa-utils available which fixes this problem? Also, I have seen this problem only while using arecord, not aplay, though they both point to the same source file? Whats the reason for this?
As far as I know, nobody fixed it. Yeah, aplay = arecord, and it occurs only with arecord to be more specific, and is present on all platforms out there:
My workaround:
" arecord is only buggy, if -M and -v flags are used, and chunk_size goes to zero (which is perfectly OK).
This is the functional version of aplay:
<-----------------------------> /* show mmap buffer arragment */ if (mmap_flag && verbose) {
const snd_pcm_channel_area_t *areas; snd_pcm_uframes_t offset; int i, chunk_prev = chunk_size;
snd_pcm_avail_update(handle); err = snd_pcm_mmap_begin(handle, &areas, &offset, &chunk_size); if (err < 0) { error("snd_pcm_mmap_begin problem: %s", snd_strerror(err)); exit(EXIT_FAILURE); } for (i = 0; i < hwparams.channels; i++) fprintf(stderr, "mmap_area[%i] = %p,%u,%u (%u)\n", i, areas[i].addr, areas[i].first, areas[i].step, snd_pcm_format_physical_width(hwparams.format)); if (!chunk_size) chunk_size = chunk_prev; /* not required, but for sure */ snd_pcm_mmap_commit(handle, offset, 0); } <----------------------------------_> "
Thanks & Regards, Anuj Aggarwal
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Mon, Nov 09, 2009 at 10:12:31AM +0200, Eero Nurkkala wrote:
As far as I know, nobody fixed it. Yeah, aplay = arecord, and it occurs only with arecord to be more specific, and is present on all platforms out there:
Has anyone reported whatever the problem is?
On Mon, 2009-11-09 at 11:26 +0100, ext Mark Brown wrote:
On Mon, Nov 09, 2009 at 10:12:31AM +0200, Eero Nurkkala wrote:
As far as I know, nobody fixed it. Yeah, aplay = arecord, and it occurs only with arecord to be more specific, and is present on all platforms out there:
Has anyone reported whatever the problem is? _______________________________________________
Does the below make any sense?
Call to: err = snd_pcm_mmap_begin(handle, &areas, &offset, &chunk_size); Will make the chuck_size to zero.
It's perfectly fine to be zero:
/** * \brief Application request to access a portion of direct (mmap) area * \param pcm PCM handle * \param areas Returned mmap channel areas * \param offset Returned mmap area offset in area steps (== frames) * \param frames mmap area portion size in frames (wanted on entry, contiguous available on exit) * \return 0 on success otherwise a negative error code * * It is necessary to call the snd_pcm_avail_update() function directly before * this call. Otherwise, this function can return a wrong count of available frames. * * The function should be called before a sample-direct area can be accessed. * The resulting size parameter is always less or equal to the input count of frames * and can be zero, if no frames can be processed (the ring buffer is full). * * See the snd_pcm_mmap_commit() function to finish the frame processing in * the direct areas. */ int snd_pcm_mmap_begin(snd_pcm_t *pcm, const snd_pcm_channel_area_t **areas, snd_pcm_uframes_t *offset, snd_pcm_uframes_t *frames) {
--> aplay doesn't call "snd_pcm_avail_update()" as this function suggest. I try is also, but the problem is chuck_size, when zero:
at aplay: static ssize_t pcm_read(u_char *data, size_t rcount)
returns rcount always, never reading any through readi_func!!!!
This pcm_read is called at aplay:
/* capture */ fdcount = 0; while (rest > 0) { size_t c = (rest <= (off64_t)chunk_bytes) ? (size_t)rest : chunk_bytes; size_t f = c * 8 / bits_per_frame; if (pcm_read(audiobuf, f) != f) break; if (write(fd, audiobuf, c) != c) { perror(name); exit(EXIT_FAILURE); } count -= c; rest -= c; fdcount += c; printf("here!\n"); }
--> like you see this thing is always fine:
if (pcm_read(audiobuf, f) != f) break; if (write(fd, audiobuf, c) != c) { perror(name); exit(EXIT_FAILURE); }
so it keeps on writing in the file, not reading any from ALSA. (try with strace)
-->> Aplay is buggy, period.
So the patch:
--- a/alsa-utils-1.0.21/aplay/aplay.c +++ b/alsa-utils-1.0.21/aplay/aplay-fix.c @@ -1104,7 +1104,8 @@ static void set_params(void) if (mmap_flag && verbose) { const snd_pcm_channel_area_t *areas; snd_pcm_uframes_t offset; - int i; + int i, chunk_prev = chunk_size; + snd_pcm_avail_update(handle); err = snd_pcm_mmap_begin(handle, &areas, &offset, &chunk_size); if (err < 0) { error("snd_pcm_mmap_begin problem: %s", snd_strerror(err)); @@ -1112,6 +1113,11 @@ static void set_params(void) } for (i = 0; i < hwparams.channels; i++) fprintf(stderr, "mmap_area[%i] = %p,%u,%u (%u)\n", i, areas[i].addr, areas[i].first, areas[i].step, snd_pcm_format_physical_width(hwparams.format)); + + /* Chunk size better be non-zero */ + if (!chunk_size) + chunk_size = chunk_prev; + /* not required, but for sure */ snd_pcm_mmap_commit(handle, offset, 0); }
On Mon, 9 Nov 2009, Eero Nurkkala wrote:
So the patch:
--- a/alsa-utils-1.0.21/aplay/aplay.c +++ b/alsa-utils-1.0.21/aplay/aplay-fix.c @@ -1104,7 +1104,8 @@ static void set_params(void) if (mmap_flag && verbose) { const snd_pcm_channel_area_t *areas; snd_pcm_uframes_t offset;
int i;
int i, chunk_prev = chunk_size;
err = snd_pcm_mmap_begin(handle, &areas, &offset, &chunk_size); if (err < 0) { error("snd_pcm_mmap_begin problem: %s", snd_strerror(err));snd_pcm_avail_update(handle);
@@ -1112,6 +1113,11 @@ static void set_params(void) } for (i = 0; i < hwparams.channels; i++) fprintf(stderr, "mmap_area[%i] = %p,%u,%u (%u)\n", i, areas[i].addr, areas[i].first, areas[i].step, snd_pcm_format_physical_width(hwparams.format));
/* Chunk size better be non-zero */
if (!chunk_size)
chunk_size = chunk_prev;
- /* not required, but for sure */ snd_pcm_mmap_commit(handle, offset, 0); }
This patch removes wrong chunk_size initialization (commited to alsa-utils git repo now):
diff --git a/aplay/aplay.c b/aplay/aplay.c index c7c82a1..f0fa969 100644 --- a/aplay/aplay.c +++ b/aplay/aplay.c @@ -1103,9 +1103,9 @@ static void set_params(void) /* show mmap buffer arragment */ if (mmap_flag && verbose) { const snd_pcm_channel_area_t *areas; - snd_pcm_uframes_t offset; + snd_pcm_uframes_t offset, size = chunk_size; int i; - err = snd_pcm_mmap_begin(handle, &areas, &offset, &chunk_size); + err = snd_pcm_mmap_begin(handle, &areas, &offset, &size); if (err < 0) { error("snd_pcm_mmap_begin problem: %s", snd_strerror(err)); exit(EXIT_FAILURE);
It's not necessary to call snd_pcm_avail_update() and mangle chunk_size. The debug code wants to print the structure of mmaped areas only which are available all time.
Thanks for reporting (although only your last patch makes clear where the problem is for me).
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
participants (4)
-
Aggarwal, Anuj
-
Eero Nurkkala
-
Jaroslav Kysela
-
Mark Brown