alsa hw params on SB Pro

alsa hw params on SB Pro

[Ryan Underwood]

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


Hi,

I seem to have the following problem.  On snd-sb8 with a SBPro (which is
capable of stereo), the best stereo playback mode is 22KHz - going above
22KHz implies that the output will be only one channel.

If I call snd_pcm_hw_params_set_channels_near with argument of 2
channels, I get 2 channels as requested.  But then I call
snd_pcm_hw_params_set_rate_near with argument of 44100, and have 44100
returned.  Thus I end up with a hwparams that the hardware is not
capable of.

Is there a reason the second call returns 44100 instead of 22050?
Conversely, calling _set_rate_near first and having 44100 returned
should mean that I only get 1 channel returned from _set_channels_near.
Isn't this the point of _near functions after all?

This is with libasound 1.0.8 and drivers version 1.0.8+2 from debian
(kernel 2.4.27).

Thanks,

-- 
Ryan Underwood, <nemesis@icequake.net>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: alsa hw params on SB Pro

[Takashi Iwai]

At Mon, 7 Feb 2005 23:36:06 -0600,
Ryan Underwood wrote:
> 
> Hi,
> 
> I seem to have the following problem.  On snd-sb8 with a SBPro (which is
> capable of stereo), the best stereo playback mode is 22KHz - going above
> 22KHz implies that the output will be only one channel.
> 
> If I call snd_pcm_hw_params_set_channels_near with argument of 2
> channels, I get 2 channels as requested.  But then I call
> snd_pcm_hw_params_set_rate_near with argument of 44100, and have 44100
> returned.  Thus I end up with a hwparams that the hardware is not
> capable of.
> 
> Is there a reason the second call returns 44100 instead of 22050?
> Conversely, calling _set_rate_near first and having 44100 returned
> should mean that I only get 1 channel returned from _set_channels_near.
> Isn't this the point of _near functions after all?
> 
> This is with libasound 1.0.8 and drivers version 1.0.8+2 from debian
> (kernel 2.4.27).

Looking at sb8_main.c, the driver seems to try tighter the hw
constraint when channels=2 is set.  If this doesn't work, this might
be a bug of hw params configurator.


Takashi


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: alsa hw params on SB Pro

[Giuliano Pochini]

On Thu, 10 Feb 2005, Takashi Iwai wrote:

> At Mon, 7 Feb 2005 23:36:06 -0600,
> Ryan Underwood wrote:
> >
> > I seem to have the following problem.  On snd-sb8 with a SBPro (which is
> > capable of stereo), the best stereo playback mode is 22KHz - going above
> > 22KHz implies that the output will be only one channel.
> >
> > If I call snd_pcm_hw_params_set_channels_near with argument of 2
> > channels, I get 2 channels as requested.  But then I call
> > snd_pcm_hw_params_set_rate_near with argument of 44100, and have 44100
> > returned.  Thus I end up with a hwparams that the hardware is not
> > capable of.

Are you sure ?  IIRC the sbpro can do 44100Hz stereo. It had a "double
speed" mode that must be activated to go above 22KHz. Well, I don't
rebember exactly because I never programmed one, but I'm quite sure it
can.


--
Giuliano.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: alsa hw params on SB Pro

[Clemens Ladisch]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 991 bytes --]

Ryan Underwood wrote:
> I seem to have the following problem.  On snd-sb8 with a SBPro (which is
> capable of stereo), the best stereo playback mode is 22KHz - going above
> 22KHz implies that the output will be only one channel.
>
> If I call snd_pcm_hw_params_set_channels_near with argument of 2
> channels, I get 2 channels as requested.  But then I call
> snd_pcm_hw_params_set_rate_near with argument of 44100, and have 44100
> returned.  Thus I end up with a hwparams that the hardware is not
> capable of.

Seems to work with the attached test program:

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Pro [Sound Blaster Pro], device 0: SB8 DSP [DSP v3.2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

$ sbhwp

channels: 1-2, rate: 4000-43479
set channels to 2
channels: 2-2, rate: 10989-22223

channels: 1-2, rate: 4000-43479
set rate to 44100
channels: 1-1, rate: 43478-43479


Probably you've been using some device using the plug plugin.


Best regards,
Clemens

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1429 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <alsa/asoundlib.h>

snd_pcm_t *pcm;
snd_pcm_hw_params_t *hw_params;

#define CHECK(fn) check(fn, #fn)

void check(int err, const char *fn)
{
	if (err < 0) {
		fprintf(stderr, "%s failed: %s\n", fn, snd_strerror(err));
		exit(EXIT_FAILURE);
	}
}

void print(void)
{
	unsigned int cmin, cmax;
	unsigned int rmin, rmax;
	CHECK(snd_pcm_hw_params_get_channels_min(hw_params, &cmin));
	CHECK(snd_pcm_hw_params_get_channels_max(hw_params, &cmax));
	CHECK(snd_pcm_hw_params_get_rate_min(hw_params, &rmin, NULL));
	CHECK(snd_pcm_hw_params_get_rate_max(hw_params, &rmax, NULL));
	printf("channels: %u-%u, rate: %u-%u\n", cmin, cmax, rmin, rmax);
}

void init(void)
{
	CHECK(snd_pcm_hw_params_any(pcm, hw_params));
	CHECK(snd_pcm_hw_params_set_access(pcm, hw_params, SND_PCM_ACCESS_RW_INTERLEAVED));
	CHECK(snd_pcm_hw_params_set_format(pcm, hw_params, SND_PCM_FORMAT_U8));
	puts("");
	print();
}

int main()
{
	unsigned int c = 2, r = 44100;

	CHECK(snd_pcm_hw_params_malloc(&hw_params));
	CHECK(snd_pcm_open(&pcm, "hw:0", SND_PCM_STREAM_PLAYBACK, 0));

	init();
	printf("set channels to %u\n", c);
	CHECK(snd_pcm_hw_params_set_channels_near(pcm, hw_params, &c));
	print();

	init();
	printf("set rate to %u\n", r);
	CHECK(snd_pcm_hw_params_set_rate_near(pcm, hw_params, &r, NULL));
	print();

	CHECK(snd_pcm_close(pcm));
	return 0;
}

Re: alsa hw params on SB Pro

[Ryan Underwood]

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


On Mon, Feb 14, 2005 at 10:43:47AM +0100, Clemens Ladisch wrote:
> 
> Probably you've been using some device using the plug plugin.

Yes, this is true.  Perhaps I misunderstood the purpose of the plughw
device.  I thought it is so ALSA lib can internally convert
application's data into a suitable hardware format.  In the case of SB
Pro, it would seem reasonable that if the app is giving a 44.1KHz 2ch
stream, plughw layer would convert either to 22KHz or to 1ch for the
underlying hardware, since otherwise the playback will completely fail.

So far, I haven't found the way to make this work correctly.  I think it
can be done with asound.conf if it is really not the job of alsa-lib,
but I don't know how to only convert >22KHz streams to 1ch while leaving
other streams as 2ch.

Problem with using hw:0 directly is that this is not really a flexible
hardware in supported stream formats (U8 samples only, for example, as
well as max 2ch rate at 22KHz).  So plughw is much preferable in this
respect for app compatibility.

If there is a question why an old SBPro is still being used, well, it's
the built-in sound chip on a laptop... in fact, it is part of a CS4232
chip, but the WSS component of that chip does not work correctly with
either snd-cs4232 or snd-ad1848 - eventually after playing some sound
(sometimes for a long while), the chip locks up and must be power cycled
to restore the WSS component.  I suspect it is a problem in the
hardware, but it is very strange that e.g. SBPro and OPL components do
continue to work afterwards.  The message that I get when I attempt to
reload snd-cs4232 is:
Feb 19 19:00:37 localhost kernel: ALSA
../../alsa-kernel/isa/cs423x/cs4231_lib.c:386: cs4231_mce_down - auto
calibration time out (1)

which provides no real help, just that the CS4248 hardware seems to have
stopped responding.

-- 
Ryan Underwood, <nemesis@icequake.net>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]