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

[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

Re: [alsa-devel] [Bug #10679] 2.6.26-rc1 regression: e5e1d3cb20034a3cbcfff1f0bae12201aa2ce17e breaks artsd
by Stas Sergeev 18 May '08

18 May '08

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...

1 1

[alsa-devel] update: usb headset problem (solved)
by Anselm Reisner 17 May '08

17 May '08

Hello I found the problem. It was completely my fault. Every time the computer started I pressed the mute button but the button didn't mute the micro but froze my headset. Sorry for the trouble. Anselm

1 0

Re: [alsa-devel] Auzen X-Fi Prelude
by Kamil Kaminski 17 May '08

17 May '08

---------- Forwarded message ---------- From: Kamil Kaminski <kamilkss(a)gmail.com> Date: Sat, May 17, 2008 at 8:27 AM Subject: Re: [alsa-devel] Auzen X-Fi Prelude To: Sebastian Schneider <Sebastian.Brian(a)gmx.de> Hi Sebastian, I understand you, but I would like to kindly ask for a rough date. I believe I read somewhere in the past here that in order to make basic functionality to work you have to change subsystem id and use existing driver. What patch do I need in order to apply such a hack? I'm willing to test and even contribute, my C is very good and I can read assembly. Regards, Kamil (Kyle). On Sat, May 17, 2008 at 6:28 AM, Sebastian Schneider <Sebastian.Brian(a)gmx.de> wrote: > It's done when it's done > -- > 249 Spiele für nur 1 Preis. Die GMX Spieleflatrate schon ab 9,90 Euro. > Neu: Asterix bei den Olympischen Spielen: http://flat.games.gmx.de > _______________________________________________ > Alsa-devel mailing list > Alsa-devel(a)alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >

1 0

Re: [alsa-devel] pcsp weirdness/report (yes, even with libasound 1.0.16 revert)
by Stas Sergeev 17 May '08

17 May '08

Hi. Andreas Mohr wrote: > Immediately tried playback, and nothing worked properly. > Sound is __EXTREMELY__ silent, about 15 times more silent than the > normal terminal beep. Sorry for the silly question but... do you have the Master volume at maximum? > insmod with nforce_wa=1, no success either. nforce_wa is only needed if your speaker is completely silent otherwise. So you don't need it. > Debug output is (val has astonishingly uniform values): > input: PC Speaker as /class/input/input12 > PCSP: lpj=4012338, min_div=32, res=1 > PCSP: open called > PCSP: prepare called, size=32768 psize=2048 f=16 f1=16 > PCSP: trigger called > PCSP: start_playing called > timer_cnt 32 val 128 CUR_DIV 64 chip->treble 0 chip->max_treble 1 > timer_cnt 27 val 111 CUR_DIV 64 chip->treble 0 chip->max_treble 1 > timer_cnt 35 val 141 CUR_DIV 64 chip->treble 0 chip->max_treble 1 > timer_cnt 28 val 115 CUR_DIV 64 chip->treble 0 chip->max_treble 1 > timer_cnt 27 val 111 CUR_DIV 64 chip->treble 0 chip->max_treble 1 > timer_cnt 32 val 128 CUR_DIV 64 chip->treble 0 chip->max_treble 1 > timer_cnt 36 val 145 CUR_DIV 64 chip->treble 0 chip->max_treble 1 > timer_cnt 32 val 130 CUR_DIV 64 chip->treble 0 chip->max_treble 1 > timer_cnt 30 val 123 CUR_DIV 64 chip->treble 0 chip->max_treble 1 Only timer_cnt and val may change. Others are from the mixer controls. Well, whatever should change, seems changing. :) > BTW, since it has been frequently mentioned that sound device reordering is > an issue: > why not make that hard-coded in the driver itself?? I was thinking about that too - I don't know an answer. Added alsa-devel to CC because of that question. > If this is safe to do (setting it to a "max" value or to e.g. 10, > and all/most ALSA users still evaluate things properly), then one should > probably do it. Hopefully someone else can comment on that. > And mixer controls in gamix are very confusing, too. > E.g. when clicking on the BaseFRQ enum box, I get _two_ 18643 entries listed. I've seen this too, but I think this is a bug in that mixer gui. It doesn't seem to handle the ENUMERATED values right, IIRC. alsamixer works right. > And I'm still not sure (haven't investigated fully) > why that other setting is called "treble". Where? In the GUI or in the code? It shouldn't be called as such in the GUI, and for the code... well, I don't know, that was too long ago. :) > All in all very confusing. > All I'd want is enable playback, enable standard beep, master playback > volume and having the base frequency displayed(/changeable). Could you please see if there are any problems with alsamixer first? If not, then the problems are likely in the mixer you use. > Oh, and maybe oversampling configuration (how many samples to average, > for reduced timer load, see e.g. > http://kerneltrap.org/mailarchive/linux-activists/1993/4/13/29718 ). They seem to be talking about a simple downsampling to reduce the data transfer. I beleive they talk about downsampling in the player, not in the driver. You can't reduce the PWM freq. Making it below 18KHz would just whistle. > Oh, and why does the code order I/O sequence as > outb_p(chip->val61, 0x61); > outb_p(timer_cnt, 0x42); > outb(chip->val61 ^ 1, 0x61); > instead of > outb_p(chip->val61, 0x61); > outb(chip->val61 ^ 1, 0x61); > outb_p(timer_cnt, 0x42); > as mentioned at some other sites? Is there any reason or maybe it just > doesn't matter? I think it doesn't matter, and I did it that way to increase the delays between the port 0x61 writes. I have no proof that it helps or hurts. > Kconfig description should perhaps also be updated to prominently but > shortly display the fact that this driver provides full playback, > not just simple beeps (e.g. mention "digital sound driver" or so). It says something about a "primitive sound card", but I see no problems improving the text. > Thanks a lot for providing a rather important puzzle piece for > Linux usability! :) Ok, the problems should be solved, the texts should be improved, the users should upgrade, etc. And in a mean time, the warning I put there, is hopefully strong enough. :) If not, we can always depend that driver on CONFIG_BROKEN... but I'd like to hear more opinions about that option. Hmm, actually, why not? We can always un-depend it later. Thoughts?

2 2