[patch] snd-pcsp: put back the compatibility code

[patch] snd-pcsp: put back the compatibility code

[Stas Sergeev]

[-- Attachment #1: Type: text/plain, Size: 352 bytes --]

Hello.

The attached patch adds back the
compatibility code, allowing the
driver to work with older alsa-libs.
The removal was premature, it breaks
the real-life configs, I am sorry
about that.

Takashi, could you please apply?
It is a straight-forward revert of:
http://hg-mirror.alsa-project.org/alsa-kernel/diff/26b0243ab4fa/drivers/pcsp/pcsp_lib.c

[-- Attachment #2: pcsp_s16_back.diff --]
[-- Type: text/x-patch, Size: 2344 bytes --]

# HG changeset patch
# User Stas Sergeev <stsp@users.sourceforge.net>
# Date 1210960913 -14400
# Node ID 3887126bbd9ca422208e651d46f9f5385d409efe
# Parent  1ffcb28969441147a0480f0ad7bdc52093d1e4ee
snd-pcsp: put back the compatibility code for the older alsa-libs.

Signed-off-by: Stas Sergeev <stsp@aknet.ru>

diff -r 1ffcb2896944 -r 3887126bbd9c drivers/pcsp/pcsp_lib.c
--- a/drivers/pcsp/pcsp_lib.c	Fri May 16 12:34:47 2008 +0200
+++ b/drivers/pcsp/pcsp_lib.c	Fri May 16 22:01:53 2008 +0400
@@ -17,6 +17,8 @@ module_param(nforce_wa, bool, 0444);
 module_param(nforce_wa, bool, 0444);
 MODULE_PARM_DESC(nforce_wa, "Apply NForce chipset workaround "
 		"(expect bad sound)");
+
+#define DMIX_WANTS_S16	1
 
 static void pcsp_start_timer(unsigned long dummy)
 {
@@ -47,7 +49,7 @@ enum hrtimer_restart pcsp_do_timer(struc
 {
 	unsigned long flags;
 	unsigned char timer_cnt, val;
-	int periods_elapsed;
+	int fmt_size, periods_elapsed;
 	u64 ns;
 	size_t period_bytes, buffer_bytes;
 	struct snd_pcm_substream *substream;
@@ -92,8 +94,11 @@ enum hrtimer_restart pcsp_do_timer(struc
 		goto exit_nr_unlock2;
 
 	runtime = substream->runtime;
-	/* assume it is u8 mono */
-	val = runtime->dma_area[chip->playback_ptr];
+	fmt_size = snd_pcm_format_physical_width(runtime->format) >> 3;
+	/* assume it is mono! */
+	val = runtime->dma_area[chip->playback_ptr + fmt_size - 1];
+	if (snd_pcm_format_signed(runtime->format))
+		val ^= 0x80;
 	timer_cnt = val * CUR_DIV() / 256;
 
 	if (timer_cnt && chip->enable) {
@@ -111,7 +116,7 @@ enum hrtimer_restart pcsp_do_timer(struc
 
 	period_bytes = snd_pcm_lib_period_bytes(substream);
 	buffer_bytes = snd_pcm_lib_buffer_bytes(substream);
-	chip->playback_ptr += PCSP_INDEX_INC();
+	chip->playback_ptr += PCSP_INDEX_INC() * fmt_size;
 	periods_elapsed = chip->playback_ptr - chip->period_ptr;
 	if (periods_elapsed < 0) {
 		printk(KERN_WARNING "PCSP: playback_ptr inconsistent "
@@ -270,7 +275,11 @@ static struct snd_pcm_hardware snd_pcsp_
 	.info = (SNDRV_PCM_INFO_INTERLEAVED |
 		 SNDRV_PCM_INFO_HALF_DUPLEX |
 		 SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID),
-	.formats = SNDRV_PCM_FMTBIT_U8,
+	.formats = (SNDRV_PCM_FMTBIT_U8
+#if DMIX_WANTS_S16
+		    | SNDRV_PCM_FMTBIT_S16_LE
+#endif
+	    ),
 	.rates = SNDRV_PCM_RATE_KNOT,
 	.rate_min = PCSP_DEFAULT_SRATE,
 	.rate_max = PCSP_DEFAULT_SRATE,

Re: [patch] snd-pcsp: put back the compatibility code

[Rene Herman]

On 16-05-08 20:11, Stas Sergeev wrote:

> The attached patch adds back the
> compatibility code, allowing the
> driver to work with older alsa-libs.
> The removal was premature, it breaks
> the real-life configs, I am sorry
> about that.
> 
> Takashi, could you please apply?
> It is a straight-forward revert of:
> http://hg-mirror.alsa-project.org/alsa-kernel/diff/26b0243ab4fa/drivers/pcsp/pcsp_lib.c

Thanks. Probably .26 material; many people will likely just disable the 
driver upon not seeing it work (and not re-enable it later also, meaning 
it might be a very largely unused driver) otherwise.

Rene.

Re: [Bug #10679] 2.6.26-rc1 regression: e5e1d3cb20034a3cbcfff1f0bae12201aa2ce17e breaks artsd

[Stas Sergeev]

Hello.

Dave Jones wrote:
> Unless someone has 10 sound cards :-)  (Sounds bizarre, but I never tire
> of seeing some of the creative situations our users get themselves into).
Yes, the hardcoded values sucks...

> Something like this is probably the only real supportable way to do it though.
> It would be great if alsa took something like -1 to mean 'never make this default'.
-1 seems to be already reserved for
"use first free slot", but maybe it
would be nice to reserve some value
for the "movable" index. For example,
the index -2 can mean "use the first
free slot, but move to the next one
when some other driver is registering
with -1 or explicitly to that slot".
Of course I have no idea whether this
is possible and acceptable, but maybe
the alsa guys can tell.

> But until that lands in a module-init-tools update, we're kind of stuck.
Well, they won't take 10 or any other
value I guess...

Re: [Bug #10679] 2.6.26-rc1 regression: e5e1d3cb20034a3cbcfff1f0bae12201aa2ce17e breaks artsd

[Stas Sergeev]

Stas Sergeev wrote:
> for the "movable" index. For example,
> the index -2 can mean "use the first
> free slot, but move to the next one
> when some other driver is registering
> with -1 or explicitly to that slot".
> Of course I have no idea whether this
> is possible and acceptable, but maybe
... and for the obvious reasons this can't
work.

Re: [Bug #10679] 2.6.26-rc1 regression: e5e1d3cb20034a3cbcfff1f0bae12201aa2ce17e breaks artsd

[Stas Sergeev]

Hello.

Dave Jones wrote:
> More seriously, it doesn't seem that there's any way we can build
> this driver modular without it screwing up already working systems
Actually, I have just upgraded
f8->f9, and guess what? Lost the
sound... And not because of snd-pcsp,
but rather because snd-hda-intel
started to take the first slot
and snd-intel8x0 takes the second.
On f8 snd-hda-intel have never been
loaded for me at all. I don't need
it, it finds a HDA chip on an ATI
video board, which it never did before.

So... it doesn't look like this
problem is specific to snd-pcsp.
Anyone can get into that trouble
it seems.

Re: [Bug #10679] 2.6.26-rc1 regression: e5e1d3cb20034a3cbcfff1f0bae12201aa2ce17e breaks artsd

[Takashi Iwai]

At Sun, 18 May 2008 07:13:07 +0400,
Stas Sergeev wrote:
> 
> Hello.
> 
> Dave Jones wrote:
> > More seriously, it doesn't seem that there's any way we can build
> > this driver modular without it screwing up already working systems
> Actually, I have just upgraded
> f8->f9, and guess what? Lost the
> sound... And not because of snd-pcsp,
> but rather because snd-hda-intel
> started to take the first slot
> and snd-intel8x0 takes the second.
> On f8 snd-hda-intel have never been
> loaded for me at all. I don't need
> it, it finds a HDA chip on an ATI
> video board, which it never did before.
> 
> So... it doesn't look like this
> problem is specific to snd-pcsp.
> Anyone can get into that trouble
> it seems.

You can better use slots option for snd module instead of specifying
index in each driver for 2.6.25 or later kernels.  That is,

	options snd slots=snd-intel8x0,snd-hda-intel

will assign the specified drivers in the first two slots.  And this
means also that these two slots are reserved.  The other drivers,
e.g. a hotplugged usb-audio, won't be assigned in these slots even
usb-audio is loaded before intel8x0.

See ALSA-Configuration.txt for details.


Takashi

Re: [Bug #10679] 2.6.26-rc1 regression: e5e1d3cb20034a3cbcfff1f0bae12201aa2ce17e breaks artsd

[Stas Sergeev]

Hello.

Takashi Iwai wrote:
> You can better use slots option for snd module instead of specifying
> index in each driver for 2.6.25 or later kernels.  That is,
> 	options snd slots=snd-intel8x0,snd-hda-intel
Thanks.
How about this:
	options snd slots=!snd-pcsp
I guess implementing something like
this, is asking for a troubles, but
maybe this can be a chip solution
for the snd-pcsp problem...

Re: [Bug #10679] 2.6.26-rc1 regression: e5e1d3cb20034a3cbcfff1f0bae12201aa2ce17e breaks artsd

[Takashi Iwai]

At Thu, 22 May 2008 08:38:08 +0400,
Stas Sergeev wrote:
> 
> Hello.
> 
> Takashi Iwai wrote:
> > You can better use slots option for snd module instead of specifying
> > index in each driver for 2.6.25 or later kernels.  That is,
> > 	options snd slots=snd-intel8x0,snd-hda-intel
> Thanks.
> How about this:
> 	options snd slots=!snd-pcsp
> I guess implementing something like
> this, is asking for a troubles, but
> maybe this can be a chip solution
> for the snd-pcsp problem...

This sounds like an interesting idea.  Will check later.


thanks,

Takashi