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

Re: [alsa-devel] problems compiling alsa-drivers-1.0.16 into 2.6.25.4 kernel
by Takashi Iwai 20 May '08

20 May '08

At Tue, 20 May 2008 03:03:44 +0200, Dragan Noveski wrote: > > hallo list, > steven rostedt asked me to pass this problem to this list, so here it goes. No, it should be alsa-devel ML. > when running make in the alsa-driver source i get this error: > > ..... > make[1]: Entering directory `/usr/src/linux-2.6.25' ALSA 1.0.16 doesn't work for 2.6.25 kernel. Get the latest HG version. Takashi

2 1

[alsa-devel] Fwd: Re: Incorrect model selection for HDA Intel based card.
by Travis Place 19 May '08

19 May '08

Below (as well as attached) is my patch, for the 0x814e variant of the ASUS P5GD1 w/SPDIF. diff -r e2b60934d1c8 pci/hda/patch_realtek.c --- a/pci/hda/patch_realtek.c Mon May 19 12:32:25 2008 +0200 +++ b/pci/hda/patch_realtek.c Tue May 20 01:50:04 2008 +1000 @@ -2981,7 +2981,7 @@ static struct snd_pci_quirk alc880_cfg_t /* SND_PCI_QUIRK(0x1043, 0x1964, "ASUS", ALC880_ASUS_DIG), */ SND_PCI_QUIRK(0x1043, 0x1973, "ASUS", ALC880_ASUS_DIG), SND_PCI_QUIRK(0x1043, 0x19b3, "ASUS", ALC880_ASUS_DIG), - SND_PCI_QUIRK(0x1043, 0x814e, "ASUS", ALC880_ASUS), + SND_PCI_QUIRK(0x1043, 0x814e, "ASUS P5GD1 w/SPDIF", ALC880_6ST_DIG), SND_PCI_QUIRK(0x1043, 0x8181, "ASUS P4GPL", ALC880_ASUS_DIG), SND_PCI_QUIRK(0x1043, 0x8196, "ASUS P5GD1", ALC880_6ST), SND_PCI_QUIRK(0x1043, 0x81b4, "ASUS", ALC880_6ST), Changelog: Corrected the model assignment for the ASUS P5GD1 w/SPDIF after reports of surround sound not being possible. Signed-off-by: Travis Place <wishie at wishie dot net>

1 0

[alsa-devel] Incorrect model selection for HDA Intel based card.
by Travis Place 19 May '08

19 May '08

Just had a user in #alsa on freenode, with an Asus P5GD1 mainboard. They couldnt seem to get surround sound working at all. It has an ALC880 based HDA-Intel sound device on board. Now, the problem lies in the Susbsystem ID's (1043:814e). These match in patch_realtek.c as follows: SND_PCI_QUIRK(0x1043, 0x814e, "ASUS", ALC880_ASUS) The users mainboard (The ASUS P5GD1) actually has 6 output jacks, aswell as SPDIF, not the standard 3-jacks that the "ASUS" model quirk implies. I talked this user through forcing the driver to use '6stack-digout' for his sound device, and things all work fine now. Below is a link to his alsa-info output, with the problem fixed. (so you can check IDs etc) http://pastebin.ca/1022042 Up until this point, i hadnt come across a wrong detection like that. Is there anyway to differentiate this users card from the normal "3stack" model that actually requires the "ASUS" model quirk ? Thanks, Travis Place -- Happiness is like peeing your pants. Everyone can see it, but only you can feel its warmth

2 8

[alsa-devel] [PATCH] Support for Roland SonicCell sound module
by Chris Mennie 19 May '08

19 May '08

I'm not sure if this is the right place for it, but I've added support for the Roland SonicCell sound module. Patches were made against alsa-driver-1.0.16 source. Please let me know if there's a better place to post this: --- usbquirks.h 2008-02-05 04:23:24.000000000 -0500 +++ usbquirks.h 2008-05-18 13:02:32.000000000 -0400 @@ -1367,6 +1367,39 @@ } }, +{ + /* Roland SonicCell */ + USB_DEVICE(0x0582, 0x00c2), + .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { + .vendor_name = "Roland", + .product_name = "SonicCell", + .ifnum = QUIRK_ANY_INTERFACE, + .type = QUIRK_COMPOSITE, + .data = (const struct snd_usb_audio_quirk[]) { + { + .ifnum = 0, + .type = QUIRK_AUDIO_STANDARD_INTERFACE + }, + { + .ifnum = 1, + .type = QUIRK_AUDIO_STANDARD_INTERFACE + }, + { + .ifnum = 2, + .type = QUIRK_MIDI_FIXED_ENDPOINT, + .data = & (const struct snd_usb_midi_endpoint_info) { + .out_cables = 0x0001, + .in_cables = 0x0001 + } + }, + { + .ifnum = -1 + } + } + } +}, + + /* Guillemot devices */ { /*

2 4

[alsa-devel] [ALC262_FUJITSU patch_realtek.c] Use jack sense for both headphone outputs
by Tony Vroon 19 May '08

19 May '08

Good morning, Could you please consider the following patch for 2.6.27. The driver starts up with the jacks in an inconsistent state (speakers on, laptop headphone output enabled, dock headphone output enabled) and does not consider their state until the first unsolicited event arrives. In some cases it takes *headphone insert* *headphone removal* *headphone insert* to get the driver to mute the speakers successfully. Also, both HP outputs are enabled together, rather then individually enabled based on jack sense results. This patch addresses both problems. Open to comments as usual & sign-off in diff. Regards, Tony V. LINX sysadmin

2 5

[alsa-devel] pyalsa with threads allowed for python (Py_BEGIN_ALLOW_THREADS & Py_END_ALLOW_THREADS)
by ki.ber.kom.uni.st 19 May '08

19 May '08

i develop my app iterating ipython interactive sessions with pasting the good code into files (which eventually being loaded back to ipython sessions)... for that kind of development i need pyalsa to run in python threads... when i did (as it is now) alsaseq.Sequencer.receive_events(100) in infinite loop of pyqt4 thread it always steal interaction from ipython and it makes interaction unusable... it gets back every now and then almost randomly and definitively not frequent enough to be usable.. hope this description explained enough of what's happening... the solution was to make time.sleep(.001) at the end of while True: loop... it took me several hours to find out the solution... i was quite happy with the solution but my guru friends told me that's dirty and i'm lame... the other solution is in particular case of receive_events to put Py_*_ALLOW_THREADS Py_BEGIN_ALLOW_THREADS; ret = poll(self->receive_fds, self->receive_max, timeout); Py_END_ALLOW_THREADS; around poll... this url should explain this strange phenomena (to me) to the real programmers: http://www.python.org/doc/1.5.2/api/threads.html in my case my programming guru akapav sort it out after couple of minuts checking the code... hope this is of some interest to pyalsa devs... i definitively would need most of the functions being ready to run in threads.... thanx.. keep up the good work...

2 1

[alsa-devel] Application doing forward/rewind
by Aggarwal, Anuj 18 May '08

18 May '08

Hi, I am new to ALSA framework and currently working on an embedded platform. My ALSA driver works fine with APLAY and ARECORD utilities, which are coming along with the alsa-utils package. But they don't support forward and rewind. I wrote my own app for the same but the APIs are returning me 0, although some frames have been forwarded. I searched a lot for some simple command line based audio player which can provide me this sort of functionality but I could not find one. Can someone help? If I have missed something, please let me know. Thanks & Regards, Anuj Aggarwal

2 6

[alsa-devel] [patch] snd-pcsp: silent misleading warning
by Stas Sergeev 18 May '08

18 May '08

Hello. Roberto Oppedisano wrote: > I noticed that when I run > aplay -D plughw:2,0 /usr/share/sounds/KDE_Logout.wav > I get a flood of: > [ 417.338143] PCSP: playback_ptr inconsistent (4642 4661 18645) It turns out that the buffer size you get, is not evenly devided by period size. 18645 % 4661 = 1. That (wrongly) triggers the warning. This may very well be an alsa bug, or may not, but the code in the driver is handling that properly, so there is no need for such a verbose warning. The attached patch shuts down the warning. Takashi, could you please apply?

2 4

[alsa-devel] v2.6.25.3 BUG (due to usb audio device?)
by Avuton Olrich 18 May '08

18 May '08

This locks up KDE due to kmixer somehow trying to stay attached to the audio device after resume from suspend-to-disk. This is the second time of dealing with this (or a similar bug) with the usb audio device: http://mailman.alsa-project.org/pipermail/alsa-devel/2008-March/006867.html I got it working by using the head of the git tree recommended in that thread (unfortunately I don't have the hash it was related to). http://avuton.googlepages.com/config.gz http://avuton.googlepages.com/proc-version http://avuton.googlepages.com/lspci-vvv [ 1432.710102] BUG: unable to handle kernel paging request at 00100100 [ 1432.710102] IP: [<c039be3d>] snd_ctl_dev_disconnect+0x5d/0x90 [ 1432.710102] *pde = 00000000 [ 1432.710102] Oops: 0000 [#1] PREEMPT [ 1432.710102] Modules linked in: netconsole configfs snd_pcm_oss snd_mixer_oss [ 1432.710102] [ 1432.710102] Pid: 176, comm: khubd Not tainted (2.6.25.3 #1) [ 1432.710102] EIP: 0060:[<c039be3d>] EFLAGS: 00010246 CPU: 0 [ 1432.710102] EIP is at snd_ctl_dev_disconnect+0x5d/0x90 [ 1432.710102] EAX: 00000000 EBX: 00100100 ECX: 00020004 EDX: 0000001d [ 1432.710102] ESI: f7c7dd68 EDI: f7c7dc00 EBP: f7c7dd4c ESP: f7d33e68 [ 1432.710102] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 [ 1432.710102] Process khubd (pid: 176, ti=f7d32000 task=f7d30000 task.ti=f7d32000) [ 1432.710102] Stack: 00000000 f7d654e0 f7c7dc00 f7c7dd40 00000000 c039e0b6 c01a8630 f7d654e0 [ 1432.710102] c039e35a 00000000 f7c7dc00 c05502c0 f7c7e080 c039a561 f7d33ec4 f7d6d9c0 [ 1432.710102] f7d6c400 f7d6c41c c03be425 f7c7dc00 c04f0755 f7c3dc5c f7d6c400 f7d6c41c [ 1432.710102] Call Trace: [ 1432.710102] [<c039e0b6>] snd_device_disconnect+0x56/0x80 [ 1432.710102] [<c01a8630>] sysfs_ilookup_test+0x0/0x10 [ 1432.710102] [<c039e35a>] snd_device_disconnect_all+0x2a/0x50 [ 1432.710102] [<c039a561>] snd_card_disconnect+0x141/0x1b0 [ 1432.710102] [<c03be425>] usb_audio_disconnect+0x55/0x130 [ 1432.710102] [<c035ba18>] usb_unbind_interface+0x38/0x90 [ 1432.710102] [<c030df81>] __device_release_driver+0x51/0x90 [ 1432.710102] [<c030e3ad>] device_release_driver+0x1d/0x40 [ 1432.710102] [<c030d881>] bus_remove_device+0x51/0x80 [ 1432.710102] [<c030bf3c>] device_del+0xdc/0x150 [ 1432.710102] [<c035902a>] usb_disable_device+0x7a/0xe0 [ 1432.710102] [<c0354be9>] usb_disconnect+0x89/0xe0 [ 1432.710102] [<c0355996>] hub_thread+0x2f6/0xc90 [ 1432.710102] [<c0116e0b>] pick_next_task_fair+0x7b/0xb0 [ 1432.710102] [<c012dc40>] autoremove_wake_function+0x0/0x40 [ 1432.710102] [<c03556a0>] hub_thread+0x0/0xc90 [ 1432.710102] [<c012d912>] kthread+0x42/0x70 [ 1432.710102] [<c012d8d0>] kthread+0x0/0x70 [ 1432.710102] [<c0104b1f>] kernel_thread_helper+0x7/0x18 [ 1432.710102] ======================= [ 1432.710102] Code: 18 b9 01 00 00 00 ba 03 00 00 00 c7 04 24 00 00 00 00 e8 d7 c7 d7 ff 8d 43 20 b9 04 00 02 00 ba 1d 00 00 00 e8 65 9a dd ff 8b 1b <8b> 03 0f 18 00 90 39 f3 75 c9 89 e8 e8 12 5a d9 ff 89 fa 31 c0 [ 1432.710102] EIP: [<c039be3d>] snd_ctl_dev_disconnect+0x5d/0x90 SS:ESP 0068:f7d33e68 [ 1432.710127] ---[ end trace 1c91addd529faaa2 ]--- -- avuton -- "I've got a fever. And the only prescription is more cowbell." -- Christopher Walken

2 5

[alsa-devel] [patch] snd-pcsp: depend on CONFIG_EXPERIMENTAL
by Stas Sergeev 18 May '08

18 May '08

Hello. Considering all the feedbacks I got, depending snd-pcsp on CONFIG_EXPERIMENTAL looks like the only safe way to get out of all the troubles at one go. :) Can the attached patch be applied? Btw, it seems to me that the alsa-kernel hg tree somehow lacks a few snd-pcsp patches that the alsa git tree has... how have that happened and how can be fixed?

5 9