Please don't drop Cc to ML. Also avoid top-post.
On Tue, 05 Jul 2016 09:02:12 +0200, Trent Reed wrote:
Thanks Takashi,
My implementation does only use the "hw:N" devices, unfortunately - I am not using MMAP because I was under the impression that you must poll when directly accessing the hardware. And yes, 48kHz is the exact rate I'm attempting. :( I do have an update, though - I'm able to reproduce the issue quite simply by running the ALSA test application latency with the following command:
`latency -P <playback-device> -C <capture-device> -r 48000`
This, as far as I understand from the source code, should open R/W interleaved streams on ("hw:2" is what I'm using for both, though the problem persists in non-duplex mode, e.g. "hw:2" "hw:0") in non-blocking mode without polling.
What happens is the latency application does normalize around some value (say, 16ms roundtrip time), but the audio is awful and broken, a lot of this "static" I'm talking about. It seems to me that it's the same problem that I have in my above-mentioned sample code.
I would love to help more, so if I can in any way, please let me know! But I feel at a loss for how to further debug.
The latency program is too complex to analyze the issue. Check arecord with --nonblock --test-nowait options and with the hw device. Does the issue happen always? Or does it depend on the buffer or period size?
Takashi
Thanks,
- Trent Reed
On Mon, Jul 4, 2016 at 11:52 PM, Takashi Iwai tiwai@suse.de wrote:
On Sat, 02 Jul 2016 23:58:28 +0200, Trent Reed wrote:
(Ping)
I'm afraid I still don't understand why this is failing. I found that a call to sdn_pcm_wait() when -EAGAIN is returned fixes the problem because it waits for samples to be ready, but I don't understand why it is a problem in the first place. Much of the sample code is written in a way that suggests that the call to snd_pcm_wait() is optional, and only required when directly reading/writing from the device (MMAP, I'm not
doing
this).
I'm just wondering what is wrong with basically looping over a call to snd_pcm_readi() in non-blocking mode, reacting to errors, and capturing frames. This produces awful static (which is basically garbage samples),
is
it a requirement that I call snd_pcm_wait() when -EAGAIN is passed back
to
wait for a full period to be ready?
Well, in the API level, it should work as you expected. So there must be definitely some bug(s). But it's hard to spot out, as there are several layers behind the scene.
As a first shot, try to reproduce without alsa-lib plugins, i.e. only with "hw" PCM device, if not done yet. Also, it's interesting to see whether it happens with or without mmap r/w.
Another point is whether it depends on the parameter. Did you try 48kHz instead of 44.1kHz?
Takashi
Thanks,
- Trent Reed
On Tue, Jun 28, 2016 at 7:27 PM, Trent Reed treed0803@gmail.com wrote:
Hey All,
I've been banging my head against the wall for about a week on this
bug.
The following gist shows my sample reproduction code: https://gist.github.com/TReed0803/985c5d5c3d295245e19006a27be447c3
I'm simply opening up a non-blocking PCM capture stream and writing the contents of the reads to stdout. (Originally, I was writing to the playback stream, but I was hearing
this
strange static occasionally!)
It's the static I'm trying to debug. It doesn't happen every time. In fact, sometimes I'll go a few consecutive executions without hearing
it.
I was able to capture some of the bad data, and I loaded it up in
Audacity
for visualization:
https://drive.google.com/file/d/0B-1aumGKQcQTcUJoZzIwRWhYSFE/view?usp=sharin...
It looks like the internal buffer occasionally is sending me more data than it actually captured, and I end up either reading old PCM data
from
the internal ring buffer, or (at the very beginning) a bunch of zeros.
Can anyone help me understand what is going on? What could cause these definitely incorrect samples to be recorded? (I get the same effect regardless of hardware, but I will list hardware just in case.)
I hope I have all the information you might need: Hardware: Samson Meteor Mic (USB-Audio, USB Mixer) [Though, it even happens with my built-in microphone] ALSA version: Advanced Linux Sound Architecture Driver Version k4.4.0-28-generic. apt-cache policy (installed alsa-lib version): 1.1.0-0ubuntu1
Thanks,
- Trent Reed
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel