April 2007 - Alsa-devel - mailman.alsa-project.org

Re: [alsa-devel] Alsa OSS - who is maintaining it?
by Takashi Iwai 04 Apr '07

04 Apr '07

At Wed, 04 Apr 2007 19:18:48 +0200, Johannes Berg wrote: > > On Wed, 2007-04-04 at 19:10 +0200, Takashi Iwai wrote: > > > > > To make sure, check /proc/asound/card0/pcm0p/sub0/hw_params has no > > > > "OSS" entry when you're playing via aoss. If a line like "OSS Format" > > > > appears there, it is still kernel oss-emulation. > > > > > > OSS Format is not in there. > > > > Fine. Then it smells more. > > > > Johannes, any known / possible problem with OSS emulation using aoa > > driver (especially regarding endianness)? > > snd-pcm-oss you mean? Both snd-pcm-oss and aoss wrapper seem not working for Stefan's machine. Maybe a problem specific to a certain model? Takashi > No, it's working fine, the contents of that file is (mplayer -ao oss): > > access: RW_INTERLEAVED > format: S16_BE > subformat: STD > channels: 2 > rate: 44100 (44100/1) > period_size: 1024 > buffer_size: 16384 > tick_time: 10000 > OSS format: S16_BE > OSS channels: 2 > OSS rate: 44100 > OSS period bytes: 4096 > OSS periods: 16 > OSS period frames: 1024 > > while with alsa it is (rhythmbox/gstreamer): > > access: MMAP_INTERLEAVED > format: S16_BE > subformat: STD > channels: 2 > rate: 44100 (44100/1) > period_size: 1024 > buffer_size: 8192 > tick_time: 10000 > > and with aoss (aoa mplayer -ao oss, snd-pcm-oss not loaded): > access: MMAP_INTERLEAVED > format: S16_BE > subformat: STD > channels: 2 > rate: 44100 (44100/1) > period_size: 1024 > buffer_size: 8192 > tick_time: 10000 > > > Don't see a problem at all, working well for me.

2 1

Re: [alsa-devel] Alsa OSS - who is maintaining it?
by Takashi Iwai 04 Apr '07

04 Apr '07

At Wed, 04 Apr 2007 19:12:49 +0200, Stefan de Konink wrote: > > Takashi Iwai wrote: > > I meant the comparison between the working state with ALSA apps and > > the non-working state with OSS apps... > > Lets put it this way: > mplayer -ao oss: noise > mplayer -ao alsa: nice sound And the comparison of parameters? You can get it in /proc/asound/card0/pcm0p/sub0/* files as I already mentioned. Diff them between two different stats. Takashi

1 0

Re: [alsa-devel] Alsa OSS - who is maintaining it?
by Takashi Iwai 04 Apr '07

04 Apr '07

At Wed, 04 Apr 2007 18:57:11 +0200, Stefan de Konink wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Takashi Iwai wrote: > > Hm, then I suspect rather it's a problem in the aoa driver side. > > > > To make sure, check /proc/asound/card0/pcm0p/sub0/hw_params has no > > "OSS" entry when you're playing via aoss. If a line like "OSS Format" > > appears there, it is still kernel oss-emulation. > > OSS Format is not in there. Fine. Then it smells more. Johannes, any known / possible problem with OSS emulation using aoa driver (especially regarding endianness)? > > After you confirm it's a native ALSA in the driver execution, compare > > the parameters there between the working status (using ALSA API) and > > non-working status (OSS API). > > I never have had the aoa driver working with OSS. I'm using 1.0.14_rc3. I meant the comparison between the working state with ALSA apps and the non-working state with OSS apps... Takashi

1 0

[alsa-devel] Individual PCM stream control
by Nagalla, Hari 04 Apr '07

04 Apr '07

Hello, I am new to ALSA, so some help from experienced folks would help.. We are trying to develop ALSA support for our DSP based mixer. In our architecture DSP performs the mixing, sample rate conversion etc. My question is how, can does the user space applications exercise controlling individual PCM stream to the mixer? Ex: individual stream gain control, individual stream mute, etc.. Any user space example code would be useful too.. Thanks Hari

2 3

[alsa-devel] ALSA, GStreamer and surround
by Christian F.K. Schaller 04 Apr '07

04 Apr '07

Hi, We are still having issues resolving how to deal with Surround sound and ALSA in GStreamer. If anyone knowledgeable about ALSA would be willing to comment on this bug: http://bugzilla.gnome.org/show_bug.cgi?id=410403 We would much appreciate it. Christian

3 12

[alsa-devel] usb midi disconnect -> kernel oops
by Dmitry Baikov 04 Apr '07

04 Apr '07

Hi! If I have a running application which connects (via alsa seq) to usb midi device, and device is disconnected, I get a kernel oops. kernels tried: 2.6.20-rt8 (in-kernel alsa), 2.6.21-rc5-rt3 (in-kernel alsa, and 1.0.14_rc3) Kernel dump attached. Dmitry.

3 11

Re: [alsa-devel] SPDIF/IEC958 sample rate on HDA/ALC882
by Dag Lem 03 Apr '07

03 Apr '07

Takashi Iwai <tiwai <at> suse.de> writes: > > Hi, > > Sorry, looks like I overlooked this post... > > At Wed, 01 Nov 2006 17:58:55 +0100, > Erik Slagter wrote: > > > > Sorry if this is considered to be "user" question, but I got no response > > at all from the "user" list. Guess the real cracks hang around here. > > > > I have lots of questions I cannot resolve from all of the docs, but for > > the moment I'll stick to the most important one. > > > > The combination of HDA/ALC882 should be able to deliver sound at 96 kHz > > (hda..., right...) Also the ALC882 datasheet says it can deliver sound > > at 96 kHz. > > > > In practise, though, I cannot get it to output any other sample rate > > than 48 kHz. Any other sample rate handed to hw:0,0 is simply converted > > (somewhere??? and badly...) to 48 kHz and the SPDIF is still driven at > > 48 kHz. > > > > iecset allows me to set the rate to 32/44.1/48 kHz, the spdif output is > > still at 48 kHz. Some other flags from iecset are actually honoured > > (like "data" and "emphasis"). > > It's simply because iecset program doesn't support the rates over > 48kHz. But the hda-intel driver supports the rate, AFAIK. > (At least, there is no particular code that restricts over-48kHz.) > > One thing to be noted is that if you use "hw" PCM device, you have to > set up the SPDIF status bits _manually_ via control API. If you use > "iec958" or "spdif" PCM device, you can pass these bits as optional > arguments at opening the PCM. > > > I can ask aplay to play at various rates (from a suitable PCM file), but > > it complains at any other rate than 44.1 or 48 (notably 32) kHz that the > > rate is not supported. It plays at 44.1 kHz though. And again converts > > it to 48 kHz! Sigh... > > Who complains? At least, the driver won't. > > > Maybe I am using the wrong "hw", there is also a "hw:0,2" device, which > > I cannot make work properly at all (only one channel is output, large > > chunks are discarded, much much clipping). > > The first PCM device is for the multi-output PCM. It's for both > analog and digital. The dedicated SPDIF is the secondary one. > > Takashi > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > Hi, I was googling around and found this (old) post; I can confirm that there are severe problems with the ALC882 and/or the driver code. I'm experiencing the same problem as Erik - I cannot get the ALC882 to transmit at any other sample rate than 48kHz over S/PDIF. When I attempt to play 44.1kHz sound, the S/PDIF connection is still locked at 48kHz (shown by my amplifier), and the resulting sound is less than pleasing. It would seem like a 44.1kHz signal packed in a 48kHz frame rate played back directly - high-pitched sounds suffer badly from what my ears recognize as straightforward sample picking as opposed to resampling. Looking at hda_codec.c:convert_from_spdif_status() it seems that the IEC958 parameter bit for 44.1kHz/48kHz is not used for anything (correct me if I'm wrong). This would mean that the rate is only set in snd_hda_codec_setup_stream(), and as far as I can tell from looking at the array rate_bits and the ALC882 Series Datasheet the setting is correct for 44.1kHz. Since I can't find any obvious mistake in the HDA code, I guess there is some problem in patch_realtek.c, or an initialization incompatibility with the HDA code and the ALC882 chip. There are certainly initialization problems somewhere, as the S/PDIF output is sometimes not able to send AC3 data correctly (amplifier cannot detect AC3 and stays silent), and attempting to play audio (even 48kHz) results in intermittent screeches. This is solved by setting and resetting the IEC958 control widget, trying again and again until it finally works. When it does work, it works without a hitch until the next reboot. Any ideas? Is there anything I can help to test in order to nail down the problem? My motherboard is an Asus P5W DH Deluxe with an 82801G HDA controller, in case this has any relevance. -- Best regards, Dag Lem

4 20

[alsa-devel] Vanilla Blocked I/O probs
by Gordon Miller 03 Apr '07

03 Apr '07

Hi, I am calling rc = snd_pcm_readi (handle, buffer, MAX_LEN) but rc is always 4 short of MAX_LEN (1020 instead of 1024). I thought that it would just block until MAX_LEN frames were available. This is really doing my head in, and any help would be appreciated. Cheers

3 4

Re: [alsa-devel] Alsa OSS - who is maintaining it?
by Takashi Iwai 03 Apr '07

03 Apr '07

At Tue, 03 Apr 2007 00:35:21 +0200, Stefan de Konink wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Takashi Iwai wrote: > > At Wed, 28 Mar 2007 13:08:09 +0200 (CEST), > > Stefan de Konink wrote: > >> On Wed, 28 Mar 2007, Takashi Iwai wrote: > >> > >>> Did you try other drivers, such as usb-audio? > >> I did not. > > > > Then try it if you have one. > > Don't have one. It's a pity. > >>> And, you're using user-space alsa-oss wrapper (e.g. via aoss wrapper), > >>> right? The user-space emulation and kernel-space emulation are > >>> totally different, so I have to know what you actually tried. > >> I'm only using the in kernel translation. > > > > Then try aoss, too. > > aoss program gives the the same garbage. Hm, then I suspect rather it's a problem in the aoa driver side. To make sure, check /proc/asound/card0/pcm0p/sub0/hw_params has no "OSS" entry when you're playing via aoss. If a line like "OSS Format" appears there, it is still kernel oss-emulation. After you confirm it's a native ALSA in the driver execution, compare the parameters there between the working status (using ALSA API) and non-working status (OSS API). Takashi

1 0

[alsa-devel] USB audio class v2.0
by Daniel Mack 03 Apr '07

03 Apr '07

Hi, is there any efford taken to support devices conforming to the USB audio class in version 2.0? I'm just curious if anybody ever started work on that since I couldn't find any hint in the sources. Greets, Daniel

3 4