Re: [alsa-devel] SND_PCM_STREAM_CAPTURE and SND_PCM_NONBLOCK producing strange artifacts
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
On Tue, Jul 5, 2016 at 12:38 AM, Takashi Iwai tiwai@suse.de wrote:
Please don't drop Cc to ML. Also avoid top-post.
Whoops! Sorry - not too familiar with the etiquette yet. (Dropped Cc was an honest mistake, reply instead of reply-all).
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
It doesn't happen always, but it usually happens more often than not - sometimes I'll go a few attempts without hearing the issue, and other times it'll be consistent. The only constant seems to be that I have never heard it occur when I am running snd_pcm_wait() (e.g. without --test-nowait). I will keep trying this though to see if that ever changes.
Here are my attempted recordings:
Non-Blocking, No-Wait (produces static): `arecord -Dhw:2 -fS16_LE -r48000 -c2 --period-size=256 --nonblock --test-nowait -d5 > s16le-c2-p256-nonblock-nowait.wav` https://drive.google.com/open?id=0B-1aumGKQcQTR0ZtUFlaV1Q5cFU
Non-Blocking, Wait (does not produce static): `arecord -Dhw:2 -fS16_LE -r48000 -c2 --period-size=256 --nonblock -d5 > s16le-c2-p256-nonblock-wait.wav` https://drive.google.com/open?id=0B-1aumGKQcQTa2pGUWpTWmc1QW8
At first, I thought it had to do with the period - but here I attempt to use the default period for arecord (unsure of what the default gets set to). `arecord -Dhw:2 -fS16_LE -r48000 -c2 --nonblock --test-nowait -d5 > s16le-c2-nonblock-nowait.wav` https://drive.google.com/open?id=0B-1aumGKQcQTa280VG9LbHlreU0
To be absolutely sure that period size didn't play a role, I asked for a specific size: `arecord -Dhw:2 -fS16_LE -r48000 -c2 --period-size=1024 --nonblock --test-nowait -d5 > s16le-c2-p1024-nonblock-nowait.wav` https://drive.google.com/open?id=0B-1aumGKQcQTZlRCQ0lvek9YN3M
And it doesn't appear to relate to the sample rate: `arecord -Dhw:2 -fS16_LE -r44100 -c2 --nonblock --test-nowait -d5 > s16le-44100-c2-nonblock-nowait.wav` https://drive.google.com/open?id=0B-1aumGKQcQTZFNmTGt5VXJKQTg
I also can get it to reproduce using --mmap flag: `arecord -Dhw:2 -fS16_LE -r48000 -c2 --nonblock --test-nowait --mmap -d5 > s16le-c2-mmap-nonblock-nowait.wav` https://drive.google.com/open?id=0B-1aumGKQcQTWDZ6cFlSZjA5ek0
Let me know how I can help further debug. :)
Thanks, - Trent Reed
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
On Tue, Jul 5, 2016 at 1:46 AM, Trent Reed treed0803@gmail.com wrote:
On Tue, Jul 5, 2016 at 12:38 AM, Takashi Iwai tiwai@suse.de wrote:
Please don't drop Cc to ML. Also avoid top-post.
Whoops! Sorry - not too familiar with the etiquette yet. (Dropped Cc was an honest mistake, reply instead of reply-all).
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
It doesn't happen always, but it usually happens more often than not - sometimes I'll go a few attempts without hearing the issue, and other times it'll be consistent. The only constant seems to be that I have never heard it occur when I am running snd_pcm_wait() (e.g. without --test-nowait). I will keep trying this though to see if that ever changes.
Here are my attempted recordings:
Non-Blocking, No-Wait (produces static): `arecord -Dhw:2 -fS16_LE -r48000 -c2 --period-size=256 --nonblock --test-nowait -d5 > s16le-c2-p256-nonblock-nowait.wav` https://drive.google.com/open?id=0B-1aumGKQcQTR0ZtUFlaV1Q5cFU
Non-Blocking, Wait (does not produce static): `arecord -Dhw:2 -fS16_LE -r48000 -c2 --period-size=256 --nonblock -d5 > s16le-c2-p256-nonblock-wait.wav` https://drive.google.com/open?id=0B-1aumGKQcQTa2pGUWpTWmc1QW8
At first, I thought it had to do with the period - but here I attempt to use the default period for arecord (unsure of what the default gets set to). `arecord -Dhw:2 -fS16_LE -r48000 -c2 --nonblock --test-nowait -d5 > s16le-c2-nonblock-nowait.wav` https://drive.google.com/open?id=0B-1aumGKQcQTa280VG9LbHlreU0
To be absolutely sure that period size didn't play a role, I asked for a specific size: `arecord -Dhw:2 -fS16_LE -r48000 -c2 --period-size=1024 --nonblock --test-nowait -d5 > s16le-c2-p1024-nonblock-nowait.wav` https://drive.google.com/open?id=0B-1aumGKQcQTZlRCQ0lvek9YN3M
And it doesn't appear to relate to the sample rate: `arecord -Dhw:2 -fS16_LE -r44100 -c2 --nonblock --test-nowait -d5 > s16le-44100-c2-nonblock-nowait.wav` https://drive.google.com/open?id=0B-1aumGKQcQTZFNmTGt5VXJKQTg
I also can get it to reproduce using --mmap flag: `arecord -Dhw:2 -fS16_LE -r48000 -c2 --nonblock --test-nowait --mmap -d5 > s16le-c2-mmap-nonblock-nowait.wav` https://drive.google.com/open?id=0B-1aumGKQcQTWDZ6cFlSZjA5ek0
Let me know how I can help further debug. :)
Thanks,
- Trent Reed
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/985c5d5c3d295245e19006a27be447
c3
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=sharing
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
Hey Takashi,
Just wondering if there is any update on this or if you need any more information? Were you able to repro this? Any way I can help?
Thanks, - Trent Reed
On Sat, 06 Aug 2016 21:13:54 +0200, Trent Reed wrote:
On Tue, Jul 5, 2016 at 1:46 AM, Trent Reed treed0803@gmail.com wrote:
On Tue, Jul 5, 2016 at 12:38 AM, Takashi Iwai tiwai@suse.de wrote:
Please don't drop Cc to ML. Also avoid top-post.
Whoops! Sorry - not too familiar with the etiquette yet. (Dropped Cc was an honest mistake, reply instead of reply-all).
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
It doesn't happen always, but it usually happens more often than not - sometimes I'll go a few attempts without hearing the issue, and other times it'll be consistent. The only constant seems to be that I have never heard it occur when I am running snd_pcm_wait() (e.g. without --test-nowait). I will keep trying this though to see if that ever changes.
Here are my attempted recordings:
Non-Blocking, No-Wait (produces static): `arecord -Dhw:2 -fS16_LE -r48000 -c2 --period-size=256 --nonblock --test-nowait -d5 > s16le-c2-p256-nonblock-nowait.wav` https://drive.google.com/open?id=0B-1aumGKQcQTR0ZtUFlaV1Q5cFU
Non-Blocking, Wait (does not produce static): `arecord -Dhw:2 -fS16_LE -r48000 -c2 --period-size=256 --nonblock -d5 > s16le-c2-p256-nonblock-wait.wav` https://drive.google.com/open?id=0B-1aumGKQcQTa2pGUWpTWmc1QW8
At first, I thought it had to do with the period - but here I attempt to use the default period for arecord (unsure of what the default gets set to). `arecord -Dhw:2 -fS16_LE -r48000 -c2 --nonblock --test-nowait -d5 > s16le-c2-nonblock-nowait.wav` https://drive.google.com/open?id=0B-1aumGKQcQTa280VG9LbHlreU0
To be absolutely sure that period size didn't play a role, I asked for a specific size: `arecord -Dhw:2 -fS16_LE -r48000 -c2 --period-size=1024 --nonblock --test-nowait -d5 > s16le-c2-p1024-nonblock-nowait.wav` https://drive.google.com/open?id=0B-1aumGKQcQTZlRCQ0lvek9YN3M
And it doesn't appear to relate to the sample rate: `arecord -Dhw:2 -fS16_LE -r44100 -c2 --nonblock --test-nowait -d5 > s16le-44100-c2-nonblock-nowait.wav` https://drive.google.com/open?id=0B-1aumGKQcQTZFNmTGt5VXJKQTg
I also can get it to reproduce using --mmap flag: `arecord -Dhw:2 -fS16_LE -r48000 -c2 --nonblock --test-nowait --mmap -d5 > s16le-c2-mmap-nonblock-nowait.wav` https://drive.google.com/open?id=0B-1aumGKQcQTWDZ6cFlSZjA5ek0
Let me know how I can help further debug. :)
Thanks,
- Trent Reed
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/985c5d5c3d295245e19006a27be447
c3
> > 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=sharing
> > 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
Hey Takashi,
Just wondering if there is any update on this or if you need any more information? Were you able to repro this? Any way I can help?
Sorry, I really have no time to check this issue right now. Hopefully someone else tackles it...
Takashi
participants (2)
-
Takashi Iwai -
Trent Reed