control switch API/code change? (fwd)

control switch API/code change? (fwd)

[Taybin Rutkin]

I'm sending this message on behalf of Paul Davis.

---------- Forwarded message ----------
Date: Tue, 12 Feb 2002 15:08:56 -0500
From: Paul Davis <pbd@op.net>
To: trutkin@physics.clarku.edu
Subject: control switch API/code change?

[ TAYBIN: for some reason, i can't send mail to alsa-devel right now.
  Could you forward this for me? Thanks. ]

the code below used to work just fine with an older version of
0.9.X. i just upgraded to current CVS, and found that it now causes a
segfault by overwriting h->driver->ctl_handle, apparently before we
even get to the first snd_ctl_elem_read().

for clarity, h->driver->ctl_handle is a snd_ctl_t previously opened
successfully and correctly initialized on entry to this code.

does this ring any bells in anyone's head about changes in the control
interface code?

--p


static void *
hammerfall_monitor_controls (void *arg)

{
	jack_hardware_t *hw = (jack_hardware_t *) arg;
	hammerfall_t *h = (hammerfall_t *) hw->private;
	snd_ctl_elem_id_t *switch_id[3];
	snd_ctl_elem_value_t *sw[3];

	pthread_setcanceltype (PTHREAD_CANCEL_ASYNCHRONOUS, NULL);

	snd_ctl_elem_id_malloc (&switch_id[0]);
	snd_ctl_elem_id_malloc (&switch_id[1]);
	snd_ctl_elem_id_malloc (&switch_id[2]);

	snd_ctl_elem_value_malloc (&sw[0]);
	snd_ctl_elem_value_malloc (&sw[1]);
	snd_ctl_elem_value_malloc (&sw[2]);

	set_control_id (switch_id[0], "ADAT1 Sync Check");
	set_control_id (switch_id[1], "ADAT2 Sync Check");
	set_control_id (switch_id[2], "ADAT3 Sync Check");

	snd_ctl_elem_value_set_id (sw[0], switch_id[0]);
	snd_ctl_elem_value_set_id (sw[1], switch_id[1]);
	snd_ctl_elem_value_set_id (sw[2], switch_id[2]);

	while (1) {
		if (snd_ctl_elem_read (h->driver->ctl_handle, sw[0])) {
			jack_error ("cannot read control switch 0 ...");
		}
		hammerfall_check_sync (h, sw[0]);

		if (snd_ctl_elem_read (h->driver->ctl_handle, sw[1])) {
			jack_error ("cannot read control switch 0 ...");
		}
		hammerfall_check_sync (h, sw[1]);

		if (snd_ctl_elem_read (h->driver->ctl_handle, sw[2])) {
			jack_error ("cannot read control switch 0 ...");
		}
		hammerfall_check_sync (h, sw[2]);
		
		if (nanosleep (&h->monitor_interval, 0)) {
			break;
		}
	}

	pthread_exit (0);
}


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: control switch API/code change? (fwd)

[Jaroslav Kysela]

On Tue, 12 Feb 2002, Taybin Rutkin wrote:

> I'm sending this message on behalf of Paul Davis.
>
> ---------- Forwarded message ----------
> Date: Tue, 12 Feb 2002 15:08:56 -0500
> From: Paul Davis <pbd@op.net>
> To: trutkin@physics.clarku.edu
> Subject: control switch API/code change?
>
> [ TAYBIN: for some reason, i can't send mail to alsa-devel right now.
>   Could you forward this for me? Thanks. ]
>
> the code below used to work just fine with an older version of
> 0.9.X. i just upgraded to current CVS, and found that it now causes a
> segfault by overwriting h->driver->ctl_handle, apparently before we
> even get to the first snd_ctl_elem_read().
>
> for clarity, h->driver->ctl_handle is a snd_ctl_t previously opened
> successfully and correctly initialized on entry to this code.
>
> does this ring any bells in anyone's head about changes in the control
> interface code?

Strange. I have no clue, there were no changes in the control API. Paul,
could you try 'alsa-devel@alsa-project.org' e-mail for the alsa-devel
mailing list?

>
> --p
>
>
> static void *
> hammerfall_monitor_controls (void *arg)
>
> {
> 	jack_hardware_t *hw = (jack_hardware_t *) arg;
> 	hammerfall_t *h = (hammerfall_t *) hw->private;
> 	snd_ctl_elem_id_t *switch_id[3];
> 	snd_ctl_elem_value_t *sw[3];
>
> 	pthread_setcanceltype (PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
>
> 	snd_ctl_elem_id_malloc (&switch_id[0]);
> 	snd_ctl_elem_id_malloc (&switch_id[1]);
> 	snd_ctl_elem_id_malloc (&switch_id[2]);
>
> 	snd_ctl_elem_value_malloc (&sw[0]);
> 	snd_ctl_elem_value_malloc (&sw[1]);
> 	snd_ctl_elem_value_malloc (&sw[2]);
>
> 	set_control_id (switch_id[0], "ADAT1 Sync Check");
> 	set_control_id (switch_id[1], "ADAT2 Sync Check");
> 	set_control_id (switch_id[2], "ADAT3 Sync Check");
>
> 	snd_ctl_elem_value_set_id (sw[0], switch_id[0]);
> 	snd_ctl_elem_value_set_id (sw[1], switch_id[1]);
> 	snd_ctl_elem_value_set_id (sw[2], switch_id[2]);
>
> 	while (1) {
> 		if (snd_ctl_elem_read (h->driver->ctl_handle, sw[0])) {
> 			jack_error ("cannot read control switch 0 ...");
> 		}
> 		hammerfall_check_sync (h, sw[0]);
>
> 		if (snd_ctl_elem_read (h->driver->ctl_handle, sw[1])) {
> 			jack_error ("cannot read control switch 0 ...");
> 		}
> 		hammerfall_check_sync (h, sw[1]);
>
> 		if (snd_ctl_elem_read (h->driver->ctl_handle, sw[2])) {
> 			jack_error ("cannot read control switch 0 ...");
> 		}
> 		hammerfall_check_sync (h, sw[2]);
>
> 		if (nanosleep (&h->monitor_interval, 0)) {
> 			break;
> 		}
> 	}
>
> 	pthread_exit (0);
> }

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA Project  http://www.alsa-project.org



_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

0.9.X missing support for ES1688 on HP Omnibook 800...

[Jay Summet]

Hello all,

I own and use (as my primary machine) an HP Omnibook 800 laptop. It has
an ESS1888 sound chip which was supported using the es-1688 driver as of ALSA
0.5.12a (driver).

You had to include the following options:
options snd-card-es1688 snd_port=0x220 snd_dma8_size=32 snd_dma8=1 snd_irq=5

<of which I believe the snd_dma8_size=32 is the most important>

Trying out Alsa development (0.9.0 beta 10) version, the option
"snd_dma8_size" is no longer supported, and the alsa drivers are unable to detect/use my sound card chip.

It seems sort of bad to loose support for hardware when upgrading software, normally you are supposed to gain support ;>

For your information, the Kernel 2.0.x drivers supported the ESS1888 out of the box, but Kernels 2.2.x and 2.4.x (as well as 2.5.x) have some issues, which is why I'm using ALSA. (One specific issue is that kernels past 2.0  assume the buffer size is 64K (vs 32K) )

I don't know much about programming for sound hardware, and I'm hopeing that with this report somebody who works on the 1688 driver will say "DOH! I know what's wrong!" and be able to fix it quickly.  (It works in the old code, so you have something to compare with....)

Anyways, if you need help testing this issue on HP 800 hardware, feel free to email, I can either test code for you, or, if you are really serious and have lots of experience with the ES1688 driver, provide a laptop to develop it on.

Thanks,
Jay


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel