[alsa-devel] PATCH: ESI Juli@ fails to set sample rate
This one-line patch fixes bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/441446 and is likely to fix bug https://bugzilla.redhat.com/show_bug.cgi?id=525595 as well.
The problem for me is that if two streams are started immediately after one another (such as a playback and a recording stream, e g pulseaudio does that on startup), the call to hw_params fail with EBUSY. This patch makes the call succeed, and playback and recording works.
I do not have any other ice1724 soundcard than the ESI Juli@ so I don't know if/how this patch will affect them.
// David
At Fri, 09 Oct 2009 21:29:55 +0200, David Henningsson wrote:
[1 <text/plain; ISO-8859-1 (7bit)>] This one-line patch fixes bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/441446 and is likely to fix bug https://bugzilla.redhat.com/show_bug.cgi?id=525595 as well.
The problem for me is that if two streams are started immediately after one another (such as a playback and a recording stream, e g pulseaudio does that on startup), the call to hw_params fail with EBUSY. This patch makes the call succeed, and playback and recording works.
I do not have any other ice1724 soundcard than the ESI Juli@ so I don't know if/how this patch will affect them.
Looks good and safe to me. Could you give your sign-off?
thanks,
Takashi
// David [2 ice1724-hwparams-fail.patch <text/x-patch (7bit)>] diff --git a/sound/pci/ice1712/ice1724.c b/sound/pci/ice1712/ice1724.c index cc84a83..56d1bd8 100644 --- a/sound/pci/ice1712/ice1724.c +++ b/sound/pci/ice1712/ice1724.c @@ -643,7 +643,7 @@ static int snd_vt1724_set_pro_rate(struct snd_ice1712 *ice, unsigned int rate, (inb(ICEMT1724(ice, DMA_PAUSE)) & DMA_PAUSES)) { /* running? we cannot change the rate now... */ spin_unlock_irqrestore(&ice->reg_lock, flags);
return -EBUSY;
return ((rate == ice->cur_rate) && !force) ? 0 : -EBUSY;[3 <text/plain; us-ascii (7bit)>] _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Takashi Iwai wrote:
At Fri, 09 Oct 2009 21:29:55 +0200, David Henningsson wrote:
[1 <text/plain; ISO-8859-1 (7bit)>] This one-line patch fixes bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/441446 and is likely to fix bug https://bugzilla.redhat.com/show_bug.cgi?id=525595 as well.
The problem for me is that if two streams are started immediately after one another (such as a playback and a recording stream, e g pulseaudio does that on startup), the call to hw_params fail with EBUSY. This patch makes the call succeed, and playback and recording works.
I do not have any other ice1724 soundcard than the ESI Juli@ so I don't know if/how this patch will affect them.
Looks good and safe to me. Could you give your sign-off?
Hopefully I got the things right this time (see the other message posted to alsa-devel). If the diff does not apply cleanly, it might be that I'm diffing against the wrong git tree, so to avoid that in the future, exactly what git tree would you like to be diffed against?
// David
At Sun, 11 Oct 2009 11:42:12 +0200, David Henningsson wrote:
Takashi Iwai wrote:
At Fri, 09 Oct 2009 21:29:55 +0200, David Henningsson wrote:
[1 <text/plain; ISO-8859-1 (7bit)>] This one-line patch fixes bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/441446 and is likely to fix bug https://bugzilla.redhat.com/show_bug.cgi?id=525595 as well.
The problem for me is that if two streams are started immediately after one another (such as a playback and a recording stream, e g pulseaudio does that on startup), the call to hw_params fail with EBUSY. This patch makes the call succeed, and playback and recording works.
I do not have any other ice1724 soundcard than the ESI Juli@ so I don't know if/how this patch will affect them.
Looks good and safe to me. Could you give your sign-off?
Hopefully I got the things right this time (see the other message posted to alsa-devel).
Applied now. It'd be helpful if you add me to Cc at the next time.
If the diff does not apply cleanly, it might be that I'm diffing against the wrong git tree, so to avoid that in the future, exactly what git tree would you like to be diffed against?
Depends. If the patch is a quick fix for the upstream Linus tree, then make a diff against Linus git tree. If the patch is for next next kernel release, diff against my sound git tree, either master or for-next branch: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
thanks,
Takashi
participants (2)
-
David Henningsson -
Takashi Iwai