* Re: underrun problem when short audio play
@ 2010-03-16 13:13 ANISH KUMAR
2010-03-16 13:35 ` Mark Brown
0 siblings, 1 reply; 7+ messages in thread
From: ANISH KUMAR @ 2010-03-16 13:13 UTC (permalink / raw)
To: Mark Brown; +Cc: MAHAMMADRAFI MANIYAR, alsa-devel@alsa-project.org
Thanks Mark,
>If your driver is not responding promptly to requests to terminate playback then an
underrun doesn't seem surprising.
Sometimes in my driver write calls doesn't return causing application to block forever and CPU pegged problem.
Situation:Recording going on->go to sleep->come back from sleep->start recording again->try recording
and playing back simultaneously(something like recording going on in background and you try to play short audio).
This causes write call to get blocked in playback case causing application to hangup.
This doesn't happen if we don't go to sleep.
So i think somewhere there is some problem with suspend->resume case which is difficult to figure out.
I checked driver logs after coming back from sleep.I found for some time interrupts are coming then stopped coming suddenly
So now after waking up i am reopening the playback device before opening the record device.Which has fixed the problem
but not the root cause.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: underrun problem when short audio play
2010-03-16 13:13 underrun problem when short audio play ANISH KUMAR
@ 2010-03-16 13:35 ` Mark Brown
0 siblings, 0 replies; 7+ messages in thread
From: Mark Brown @ 2010-03-16 13:35 UTC (permalink / raw)
To: ANISH KUMAR; +Cc: MAHAMMADRAFI MANIYAR, alsa-devel@alsa-project.org
On Tue, Mar 16, 2010 at 01:13:06PM +0000, ANISH KUMAR wrote:
[Reflowed into 80 columns for legibility, please take a look at
Documentation/email-clients.txt.]
> This causes write call to get blocked in playback case causing application to hangup.
> This doesn't happen if we don't go to sleep.
> So i think somewhere there is some problem with suspend->resume case which is difficult to figure out.
You hadn't mentioned suspend and resume before... Are you sure that the
drivers you are using implement suspend and resume at all? Which
drivers are you using - this is likely to be a driver or system specific
issue from what you say above?
^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <0KZD00506NL88J@ms13.samsung.com>]
* Re: underrun problem when short audio play
[not found] <0KZD00506NL88J@ms13.samsung.com>
@ 2010-03-16 14:01 ` Mark Brown
0 siblings, 0 replies; 7+ messages in thread
From: Mark Brown @ 2010-03-16 14:01 UTC (permalink / raw)
To: ANISH KUMAR; +Cc: MAHAMMADRAFI MANIYAR, alsa-devel@alsa-project.org
On Tue, Mar 16, 2010 at 01:46:20PM +0000, ANISH KUMAR wrote:
> <HTML><HEAD><TITLE>Samsung Enterprise Portal mySingle</TITLE>
> <META http-equiv=Content-Type content="text/html; charset=windows-1252">
You appear to have reset your MUA to HTML mode...
> <P>>Are you sure that the <BR>>drivers you are using implement suspend and resume at all? </P>
> <P>I am using s3c6410 code.I2S driver has suspend/resume call(jassi brar maintained).</P>
> <P>Audio codec is also having generic code for suspend/resume but don't know if that is</P>
> <P>the problem or not.However how can i verify if my codec suspend/resume has got some </P>
> <P>problem?Most likely my codec has got some configuration problems but i am not getting </P>
> <P>any pointers to debug it.Any pointers in this direction would be very helpful.</P></BODY></HTML>
It's difficult to offer any specific advice for the CODEC without any
visibility of either the hardware or the driver. In general you want to
look at what happens to the hardware when the playback has problems (do
any clocks stop or anything - presumably there is some hardware
change?), then work back from there. Might be worth trying suspend and
resume with playback running to see if that has any impact too.
It's possible that there is an issue in the CPU driver as well, I don't
know what the testing status is there. Things like suspend and resume
during activity won't always get tested, and your case with record
running is definitely fairly obscure.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: underrun problem when short audio play
@ 2010-03-16 13:47 ANISH KUMAR
0 siblings, 0 replies; 7+ messages in thread
From: ANISH KUMAR @ 2010-03-16 13:47 UTC (permalink / raw)
To: Mark Brown; +Cc: MAHAMMADRAFI MANIYAR, alsa-devel@alsa-project.org
>Are you sure that the
>drivers you are using implement suspend and resume at all?
I am using s3c6410 code.I2S driver has suspend/resume call(jassi brar maintained).
Audio codec is also having generic code for suspend/resume but don't know if that is
the problem or not.However how can i verify if my codec suspend/resume has got some
problem?Most likely my codec has got some configuration problems but i am not getting
any pointers to debug it.Any pointers in this direction would be very helpful.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: underrun problem when short audio play
@ 2010-03-11 5:27 ANISH KUMAR
0 siblings, 0 replies; 7+ messages in thread
From: ANISH KUMAR @ 2010-03-11 5:27 UTC (permalink / raw)
To: ben@simtec.co.uk
Cc: tiwai@suse.de, alsa-devel@alsa-project.org,
broonie@opensource.wolfsonmicro.com, jkysela@redhat.com,
lrg@slimlogic.co.uk
Hi All,
Just to add to my previous post.
This problem of underrun is happening towards the end of the short audio.
This causes unclear sound.This underrun is not happening with regular
music (long duration audio).
ALSA version:1.0.18a
Regards,
anish
^ permalink raw reply [flat|nested] 7+ messages in thread
* underrun problem when short audio play
@ 2010-03-09 12:44 ANISH KUMAR
2010-03-16 12:06 ` Mark Brown
0 siblings, 1 reply; 7+ messages in thread
From: ANISH KUMAR @ 2010-03-09 12:44 UTC (permalink / raw)
To: alsa-devel@alsa-project.org; +Cc: maniyar
Hi all,
I am facing a problem when i try to play short duration audio(problem is not observerd when i am
playing tones which is also short duration audio).
Somehow i am getting buffer overrun everytime i am playing short duration audio.
It is happening because of avail >= stop_threshold.
When i tried to increase the stop_threshold but then i got "same audio played again kind of echo" problem.
I can't try the solution suggested by jaroslav i.e. checking for DRAINING state in lower level driver and stop
queuing because of some design issue as in my code i don't call drain function as soon as all buffers are written.
I wait for some time(in miliseconds) and then call drain function.
Please suggest any pointers.Should i increase the buffer size or stop_threshold both of which i tried but to no use.
I am always getting underrun problem that too always in the function update_hw_ptr_post function.
How can i disable the stop_threshold check??
Thanks,
anish
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: underrun problem when short audio play
2010-03-09 12:44 ANISH KUMAR
@ 2010-03-16 12:06 ` Mark Brown
0 siblings, 0 replies; 7+ messages in thread
From: Mark Brown @ 2010-03-16 12:06 UTC (permalink / raw)
To: ANISH KUMAR; +Cc: maniyar, alsa-devel@alsa-project.org
On Tue, Mar 09, 2010 at 12:44:36PM +0000, ANISH KUMAR wrote:
> When i tried to increase the stop_threshold but then i got "same audio played again kind of echo" problem.
> I can't try the solution suggested by jaroslav i.e. checking for DRAINING state in lower level driver and stop
> queuing because of some design issue as in my code i don't call drain function as soon as all buffers are written.
> I wait for some time(in miliseconds) and then call drain function.
What is the design issue in your driver? If you're limited by that the
most obvious solution would seem to be to address that. If your driver
is not responding promptly to requests to terminate playback then an
underrun doesn't seem surprising.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-03-16 14:01 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-16 13:13 underrun problem when short audio play ANISH KUMAR
2010-03-16 13:35 ` Mark Brown
[not found] <0KZD00506NL88J@ms13.samsung.com>
2010-03-16 14:01 ` Mark Brown
-- strict thread matches above, loose matches on Subject: below --
2010-03-16 13:47 ANISH KUMAR
2010-03-11 5:27 ANISH KUMAR
2010-03-09 12:44 ANISH KUMAR
2010-03-16 12:06 ` Mark Brown
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).