Hi
All my snd_pcm_readi calls return too few frames. Also when I switch to stereo, the sound is muted. I cannot change this by adjusting period & buffer sizes. dsnoop is enabled by default. The documentation for snd_pcm_readi says that the only way that the frame count can be short is because of a signal or xrun. Well this clearly isn't the case.
I think that direct snoop is the cause of this. Are there any remedies ? because I am roundly SICK of being told that my application must be wrong "because everyone else's works". I have spent the last 3 weeks debugging an app - that always worked properly - because of the faulty dsnoop implementation.
It is abundantly clear that dsnoop is far from ready for use, but I am prepared to put some work into this. Whose idea was it to enable dsnoop by default, when it doesn't even work ? I was quite happy with OSS. Changing everything to be alsa entailed a lot of work, and I am beginning to think it was a complete waste of my time.
ICE1712, 2.6.20.6 kernel, alsa 1.0.14rc1
Gordon
At Fri, 27 Apr 2007 13:27:00 +0100, Gordon Miller wrote:
Hi
All my snd_pcm_readi calls return too few frames. Also when I switch to stereo, the sound is muted. I cannot change this by adjusting period & buffer sizes. dsnoop is enabled by default. The documentation for snd_pcm_readi says that the only way that the frame count can be short is because of a signal or xrun. Well this clearly isn't the case.
Actually, the documentation is wrong, IMO. The typical behavior of read syscall is that it returns a value actually read by that call. It doesn't guarantee whether the requested size is filled, and can be shorter than requested. As snd_pcm_readi() emulates the read syscall, it should behave in that way.
The blocking mode means that the function waits until the threshold (watermark) condition is fulfilled.
Takashi
On Fri, 27 Apr 2007, Gordon Miller wrote:
Hi
All my snd_pcm_readi calls return too few frames. Also when I switch to stereo, the sound is muted. I cannot change this by adjusting period & buffer sizes. dsnoop is enabled by default. The documentation for snd_pcm_readi says that the only way that the frame count can be short is because of a signal or xrun. Well this clearly isn't the case.
I think that direct snoop is the cause of this. Are there any remedies ? because I am roundly SICK of being told that my application must be wrong "because everyone else's works". I have spent the last 3 weeks debugging an app - that always worked properly - because of the faulty dsnoop implementation.
It is abundantly clear that dsnoop is far from ready for use, but I am prepared to put some work into this. Whose idea was it to enable dsnoop by default, when it doesn't even work ? I was quite happy with OSS. Changing everything to be alsa entailed a lot of work, and I am beginning to think it was a complete waste of my time.
ICE1712, 2.6.20.6 kernel, alsa 1.0.14rc1
Send us a clear example which configuration does not work as you expect. We need:
a) simple test tool b) reproduce error with arecord c) debug output from snd_pcm_dump() before / while you read samples
It might be that it's no dsnoop fault, but some other plugin on way screw samples / stream position.
Your e-mail gives us nothing than "Houston, we have a problem". So it's almost useless.
Jaroslav
----- Jaroslav Kysela perex@suse.cz Linux Kernel Sound Maintainer ALSA Project, SUSE Labs
On Fri, 27 Apr 2007, Takashi Iwai wrote:
At Fri, 27 Apr 2007 13:27:00 +0100, Gordon Miller wrote:
Hi
All my snd_pcm_readi calls return too few frames. Also when I switch to stereo, the sound is muted. I cannot change this by adjusting period & buffer sizes. dsnoop is enabled by default. The documentation for snd_pcm_readi says that the only way that the frame count can be short is because of a signal or xrun. Well this clearly isn't the case.
Actually, the documentation is wrong, IMO. The typical behavior of read syscall is that it returns a value actually read by that call. It doesn't guarantee whether the requested size is filled, and can be shorter than requested. As snd_pcm_readi() emulates the read syscall, it should behave in that way.
I don't think so completely. For blocking mode (!O_NONBLOCK), all possible data should be read. Only signal or an error should break this.
The read logic for dsnoop is in snd_pcm_read_areas() in pcm/pcm.c (alsa-lib).
The blocking mode means that the function waits until the threshold (watermark) condition is fulfilled.
I don't think so. The snd_pcm_read_areas() does only xfer_align alignment for wrong user input. If less frames are returned, then it is an error IMO.
Jaroslav
----- Jaroslav Kysela perex@suse.cz Linux Kernel Sound Maintainer ALSA Project, SUSE Labs
At Fri, 27 Apr 2007 15:00:22 +0200 (CEST), Jaroslav Kysela wrote:
On Fri, 27 Apr 2007, Takashi Iwai wrote:
At Fri, 27 Apr 2007 13:27:00 +0100, Gordon Miller wrote:
Hi
All my snd_pcm_readi calls return too few frames. Also when I switch to stereo, the sound is muted. I cannot change this by adjusting period & buffer sizes. dsnoop is enabled by default. The documentation for snd_pcm_readi says that the only way that the frame count can be short is because of a signal or xrun. Well this clearly isn't the case.
Actually, the documentation is wrong, IMO. The typical behavior of read syscall is that it returns a value actually read by that call. It doesn't guarantee whether the requested size is filled, and can be shorter than requested. As snd_pcm_readi() emulates the read syscall, it should behave in that way.
I don't think so completely. For blocking mode (!O_NONBLOCK), all possible data should be read. Only signal or an error should break this.
The read logic for dsnoop is in snd_pcm_read_areas() in pcm/pcm.c (alsa-lib).
In the current implementation, it may work in that way. But, in general, I'm against such a condition. It's not what read syscalls does, so there is no real reason that snd_pcm_readi() should do so.
Takashi
On Fri, 27 Apr 2007, Takashi Iwai wrote:
At Fri, 27 Apr 2007 15:00:22 +0200 (CEST), Jaroslav Kysela wrote:
On Fri, 27 Apr 2007, Takashi Iwai wrote:
Actually, the documentation is wrong, IMO. The typical behavior of read syscall is that it returns a value actually read by that call. It doesn't guarantee whether the requested size is filled, and can be shorter than requested. As snd_pcm_readi() emulates the read syscall, it should behave in that way.
I don't think so completely. For blocking mode (!O_NONBLOCK), all possible data should be read. Only signal or an error should break this.
The read logic for dsnoop is in snd_pcm_read_areas() in pcm/pcm.c (alsa-lib).
In the current implementation, it may work in that way. But, in general, I'm against such a condition. It's not what read syscalls does, so there is no real reason that snd_pcm_readi() should do so.
Well 'man 2 read' exactly explains when a less count than requested might be returned for blocking behaviour. I'm missing something? Of course, applications should not expect to read all possible frames, but under normal conditions, less count should be returned in rare cases (for the blocking mode, of course).
Jaroslav
----- Jaroslav Kysela perex@suse.cz Linux Kernel Sound Maintainer ALSA Project, SUSE Labs
At Fri, 27 Apr 2007 15:18:53 +0200 (CEST), Jaroslav Kysela wrote:
On Fri, 27 Apr 2007, Takashi Iwai wrote:
At Fri, 27 Apr 2007 15:00:22 +0200 (CEST), Jaroslav Kysela wrote:
On Fri, 27 Apr 2007, Takashi Iwai wrote:
Actually, the documentation is wrong, IMO. The typical behavior of read syscall is that it returns a value actually read by that call. It doesn't guarantee whether the requested size is filled, and can be shorter than requested. As snd_pcm_readi() emulates the read syscall, it should behave in that way.
I don't think so completely. For blocking mode (!O_NONBLOCK), all possible data should be read. Only signal or an error should break this.
The read logic for dsnoop is in snd_pcm_read_areas() in pcm/pcm.c (alsa-lib).
In the current implementation, it may work in that way. But, in general, I'm against such a condition. It's not what read syscalls does, so there is no real reason that snd_pcm_readi() should do so.
Well 'man 2 read' exactly explains when a less count than requested might be returned for blocking behaviour. I'm missing something? Of course, applications should not expect to read all possible frames, but under normal conditions, less count should be returned in rare cases (for the blocking mode, of course).
The below from man page:
================ RETURN VALUE On success, the number of bytes read is returned (zero indicates end of file), and the file position is advanced by this number. It is not an error if this number is smaller than the number of bytes requested; this may happen for example because fewer bytes are actually available right now (maybe because we were close to end-of-file, or because we are reading from a pipe, or from a terminal), or because read() was interrupted by a signal. ================
So, when fewer bytes are actually available at the moment read gets called, it may return a shorter value.
Takashi
On Fri, 27 Apr 2007, Takashi Iwai wrote:
At Fri, 27 Apr 2007 15:18:53 +0200 (CEST), Jaroslav Kysela wrote:
On Fri, 27 Apr 2007, Takashi Iwai wrote:
At Fri, 27 Apr 2007 15:00:22 +0200 (CEST), Jaroslav Kysela wrote:
On Fri, 27 Apr 2007, Takashi Iwai wrote:
Actually, the documentation is wrong, IMO. The typical behavior of read syscall is that it returns a value actually read by that call. It doesn't guarantee whether the requested size is filled, and can be shorter than requested. As snd_pcm_readi() emulates the read syscall, it should behave in that way.
I don't think so completely. For blocking mode (!O_NONBLOCK), all possible data should be read. Only signal or an error should break this.
The read logic for dsnoop is in snd_pcm_read_areas() in pcm/pcm.c (alsa-lib).
In the current implementation, it may work in that way. But, in general, I'm against such a condition. It's not what read syscalls does, so there is no real reason that snd_pcm_readi() should do so.
Well 'man 2 read' exactly explains when a less count than requested might be returned for blocking behaviour. I'm missing something? Of course, applications should not expect to read all possible frames, but under normal conditions, less count should be returned in rare cases (for the blocking mode, of course).
The below from man page:
================ RETURN VALUE On success, the number of bytes read is returned (zero indicates end of file), and the file position is advanced by this number. It is not an error if this number is smaller than the number of bytes requested; this may happen for example because fewer bytes are actually available right now (maybe because we were close to end-of-file, or because we are reading from a pipe, or from a terminal), or because read() was interrupted by a signal. ================
So, when fewer bytes are actually available at the moment read gets called, it may return a shorter value.
The problem is that in this way, there won't be any difference between blocking I/O and non-blocking I/O. I understand situation for pipes, but we can wait to get other samples and if application wants to block, why not block?
Jaroslav
----- Jaroslav Kysela perex@suse.cz Linux Kernel Sound Maintainer ALSA Project, SUSE Labs
At Fri, 27 Apr 2007 15:46:54 +0200 (CEST), Jaroslav Kysela wrote:
On Fri, 27 Apr 2007, Takashi Iwai wrote:
At Fri, 27 Apr 2007 15:18:53 +0200 (CEST), Jaroslav Kysela wrote:
On Fri, 27 Apr 2007, Takashi Iwai wrote:
At Fri, 27 Apr 2007 15:00:22 +0200 (CEST), Jaroslav Kysela wrote:
On Fri, 27 Apr 2007, Takashi Iwai wrote:
Actually, the documentation is wrong, IMO. The typical behavior of read syscall is that it returns a value actually read by that call. It doesn't guarantee whether the requested size is filled, and can be shorter than requested. As snd_pcm_readi() emulates the read syscall, it should behave in that way.
I don't think so completely. For blocking mode (!O_NONBLOCK), all possible data should be read. Only signal or an error should break this.
The read logic for dsnoop is in snd_pcm_read_areas() in pcm/pcm.c (alsa-lib).
In the current implementation, it may work in that way. But, in general, I'm against such a condition. It's not what read syscalls does, so there is no real reason that snd_pcm_readi() should do so.
Well 'man 2 read' exactly explains when a less count than requested might be returned for blocking behaviour. I'm missing something? Of course, applications should not expect to read all possible frames, but under normal conditions, less count should be returned in rare cases (for the blocking mode, of course).
The below from man page:
================ RETURN VALUE On success, the number of bytes read is returned (zero indicates end of file), and the file position is advanced by this number. It is not an error if this number is smaller than the number of bytes requested; this may happen for example because fewer bytes are actually available right now (maybe because we were close to end-of-file, or because we are reading from a pipe, or from a terminal), or because read() was interrupted by a signal. ================
So, when fewer bytes are actually available at the moment read gets called, it may return a shorter value.
The problem is that in this way, there won't be any difference between blocking I/O and non-blocking I/O. I understand situation for pipes, but we can wait to get other samples and if application wants to block, why not block?
I think it's a difference between zero and fewer bytes. When nothing is available, it should block. After all, the blocking behavior isn't strictly defined. I guess it's rather loose in many real implementations.
What I'm suggesting here is not to change the current semantics in alsa-lib, but just to remove the sentense in the document. It's not a standard guarantee for read although we suppose to do that.
Takashi
participants (3)
-
Gordon Miller -
Jaroslav Kysela -
Takashi Iwai