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

[alsa-devel] [PATCH] SOUND: usb/endpoint, fix dangling pointer use
by Jiri Slaby 21 Jun '10

21 Jun '10

Stanse found that in snd_usb_parse_audio_endpoints, there is a dangling pointer dereference. When snd_usb_parse_audio_format fails, fp is freed, and continue invoked. On the next loop, there is "fp && fp->altsetting == 1 && fp->channels == 1" test, but fp is set from the last iteration (but is bogus) and thus ilegally dereferenced. Set fp to NULL before "continue". Signed-off-by: Jiri Slaby <jslaby(a)suse.cz> Cc: Daniel Mack <daniel(a)caiaq.de> Cc: Clemens Ladisch <clemens(a)ladisch.de> Cc: Takashi Iwai <tiwai(a)suse.de> --- sound/usb/endpoint.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c index 9593b91..6f6596c 100644 --- a/sound/usb/endpoint.c +++ b/sound/usb/endpoint.c @@ -427,6 +427,7 @@ int snd_usb_parse_audio_endpoints(struct snd_usb_audio *chip, int iface_no) if (snd_usb_parse_audio_format(chip, fp, format, fmt, stream, alts) < 0) { kfree(fp->rate_table); kfree(fp); + fp = NULL; continue; } -- 1.7.1

3 2

[alsa-devel] redirecting audio to another desktop machine
by Viral Mehta 21 Jun '10

21 Jun '10

Hi list, I have an embedded device running linux kernel and a minimal filesystem. I want to access this device remotely which means I should be able to connect to the device just like we do Remote Desktop over ethernet. I am able to do this. I am able to send key-event and framebuffer data whenever my desktop machine connects to the device. But, I am not able to send audio data on remote side. I am really not sure which device file (/dev/snd/ ???) I should read and capture the data and should send across.... Or can I read the playback device ? I think NO. Do I need to create some kind of virtual sound device ? Any pointers/suggestions are appreciated. Thanks, Viral This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________

1 0

[alsa-devel] Creative Labs [SB X-Fi Xtreme Audio] CA0110-IBG no sound
by PChot 21 Jun '10

21 Jun '10

Hi all, i'm still having problems with my audio card CA0110 which uses snd-hda-intel. I'l having same problems as other that is there is no sound. After searching on net i find that people are having pretty much the same problem http://bbs.archlinux.org/viewtopic.php?id=92769 https://bugzilla.novell.com/show_bug.cgi?id=564324 http://forums.gentoo.org/viewtopic-t-811741.html?sid=0dec2bfdd962d29f54f294… The best example how is not working is as i start mplayer. The program runs but then there is no playing video. So i could be that is not snd-hda-intel but some connected codecs. Now i'm wondering is anyone working on this case? Who shall i contact that works on snd-hda-intel or on Creative cards? So i can contact them and try to help if possible. Please someone response. Thanks, Jan

1 0

Re: [alsa-devel] PROBLEM: SIS7019 stops recording after 42 min
by Raymond Yau 21 Jun '10

21 Jun '10

2010/6/21 David Dillow <dave(a)thedillows.org> > On Mon, 2010-06-21 at 08:47 +0800, Raymond Yau wrote: > > 2010/6/20 David Dillow <dave(a)thedillows.org> > > > > > Please keep me on the cc list, I'll see your message sooner in my Inbox > > > than my mailing list folders. > > Please don't trim the cc list when replying. If you inadvertently hit > reply instead of reply-to-all, my apologies. > > > AFAIK , pulse device did not support MMAP > > Thanks, that's a pretty good clue he's using the hardware device. > Unfortunately, that means either I have bug in my driver or he's got too > much system noise and hitting overruns. > > 17:41:30.646532 access("/usr/share/alsa/cards/SiS7019.conf", R_OK) = -1 ENOENT (No such file or directory) There is no aliase for SiS7019 entry in /usr/share/alsa/cards/aliases.conf

1 0

Re: [alsa-devel] Problem on wm8974 alsa driver
by Mark Brown 20 Jun '10

20 Jun '10

On Sun, Jun 20, 2010 at 01:48:03AM +0800, jjinfo(a)nudt.edu.cn wrote: > By now, we can confirm that the digital signal has arrived the wm8974 > DAI interface. As per wm8974 manual, it is required to set some 8974 > registers(such as enabling DAC, MONOOUT,etc) so as to get analogue > signal. > However, the codec driver (wm8974.c) does not provide any routine to > set those necessary registers. My question is, where and how are these What makes you say that the driver has no support for these things? The driver provides automatic power management and application control for audio routing and gains. This control should be fairly complete. For example, the DAC power is controlled by line 221: SND_SOC_DAPM_DAC("DAC", "HiFi Playback", WM8974_POWER3, 0, 0), This will be enabled when a playback is active and the DAC is connected to an output. > outpu-related registers of audio codec chip got correctly set up? Are > they set up by aplay via calling alsa library APIs? Must we provide > additional help functions to do such initialization? aplay only deals with streaming PCM data to the CODEC. You should use an application such as alsamixer or amixer to configure the CODEC into the desired state at runtime.

1 0

[alsa-devel] no audio output with TYAN S7025 motherboard and Realtek ALC262
by Bryan Green 20 Jun '10

20 Jun '10

Hi, I have several systems with a TYAN S7025 motherboard and Realtek ALC262 chipset. I have not been able to produce any audio output. Well, that is except for one of the systems: after a variety of tweeks and tests, I got sound working on one system, but I do not know what change enabled sound to start working, and I have not been able to reproduce the effect on the other systems. I have tested with kernels up to 2.6.33, and with ALSA version 1.0.22.1. For a non-working system, 'alsaconf' gives the following output: Unknown hardware: "HDA-Intel" "Realtek ALC262" "HDA:10ec0262,10ec0262,00100202" "0x8086" "0x3a3e" And dmesg gives the following: HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 HDA Intel 0000:00:1b.0: irq 89 for MSI/MSI-X HDA Intel 0000:00:1b.0: setting latency timer to 64 hda_codec: ALC262: BIOS auto-probing. autoconfig: line_outs=1 (0x14/0x0/0x0/0x0/0x0) speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) hp_outs=0 (0x0/0x0/0x0/0x0/0x0) mono: mono_out=0x0 dig-out=0x1e/0x0 inputs: mic=0x18, fmic=0x19, line=0x1a, fline=0x0, cd=0x1c, aux=0x0 dig-in=0x1f realtek: No valid SSID, checking pincfg 0x411111f0 for NID 0x1d realtek: Enable default setup for auto mode as fallback input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/input/input8 For the working system, the dmesg output is the same except for two lines: autoconfig: line_outs=1 (0x1b/0x0/0x0/0x0/0x0) inputs: mic=0x18, fmic=0x19, line=0x1a, fline=0x0, cd=0x1c, aux=0x14 Is there a method for tweaking these values on the non-working system to match the working system, to see if that works? I've uploaded the alsa-info output from a non-working system here: http://www.alsa-project.org/db/?f=91057bfc12790688f1d257743e53d5d0ec2ce1e2 I've uploaded the alsa-info output from the working system here: http://www.alsa-project.org/db/?f=198420f14cd0062713636408640636e6d474cf94 Thanks, -bryan

3 5

Re: [alsa-devel] Status of the Tascam US-122mkII???
by jordan johnston 20 Jun '10

20 Jun '10

hey sorry, gmail defaults to only you when i reply, EVEN when i am selecting "reply all". i just have to add the Cc: manually :| ( i wasn't taking anyone out of Cc: ) sorry, i wasn't trying "violate" the rules or anything else, okay? 1. i understand that Zen-kernel has nothing to do with alsa, other than sometimes alsa drivers for certain devices are available in Zen before they are in my distro and many others i have used. i was only explaining what Zen-kernel is and why i use it. because you asked... makes sense? 2. I am glad that you were able to give me an update on the status of these devices, as the documentation around the interweb, is out-dated, and thus very often misleading. 3. I am going to go ahead and read all of the documentation you posted links to, and i will see if i can figure out how it works. 4. I am also going to contact Tascam/Teac, as i am a paying customer - why not :) obviously they are unlikely to give a lot of information away, but maybe i can get someone who knows just how different(or similar) the implementation of the Us-122L vs. mkII really is. either way, i don't mind sitting on the phone for an hour or so / or through email to let them know they should support linux or at the very least work with ALSA a little. it sounds like a lot of these companies could have really good support under linux by A: providing info on the implementation and B: by handing a device or two, into the hands of the right people(developers/hackers)...what a shame! thanks again for all of your help. It has been a slice! jordan

1 0

Re: [alsa-devel] Status of the Tascam US-122mkII???
by Daniel Mack 20 Jun '10

20 Jun '10

*** Reply to ALL please! *** On Sat, Jun 19, 2010 at 06:51:58PM -0400, jordan johnston wrote: > On Sat, Jun 19, 2010 at 6:41 PM, Daniel Mack <daniel(a)caiaq.de> wrote: > > Well, you can assume that audio is transported over dedicated > > isochronous endpoints. The question is how audio parameters are set up. > > And you can find out by tracing the traffic and see what happens when > > you start or stop the stream, when you change the sample rate etc. > > > > now, here you are referring, to tracing in OSX, or Windows right? (like before.) Yes. > i may try that out, but as i am not versed in this stuff it may be > quite difficult > without better understanding. > > do you know of any really insightful information on the > subject(somewhere on the net). > im going to google around a bit too. Hmm, I can point you to the USB specs which gives you detailed explanation about the low-level communication on the bus: http://www.usb.org/developers/docs/usb_20_052510.zip And you can read other Linux drivers and see what they do. We have no clue what Tascam's engineers did when they designed the MK2 version, and how close they kept to the protocol specs of their earlier products. Maybe they just shifted some bytes around, maybe they completely started over. All left for you to find out :) > Ya, it was a gamble i had called the store earlier in the week, they > actually had the device i wanted. > however, i didn't end up going that day. so when i did come, it had > been sold. i then decided to take > a gamble on it. > > no big deal. - 30 day return policy, and they said it was fine that i > returned it, if i couldn't get it > supported under linux. It might take you more than 30 days to fully support it under Linux if you're going to do it yourself though ;) Daniel

1 0

Re: [alsa-devel] Status of the Tascam US-122mkII???
by Tobias Hansen 20 Jun '10

20 Jun '10

jordan johnston wrote: > sorry about that....no more re-posting... > Again, reply to all addressees of the mails, now you only replied to me. > don't revert yet!!! > > The card IS half working, i can use midi no problem with jack... > > i think the driver DOES work..... i think the problem may be in > .asoundrc or some other alsa settings. > > right now i am using .asoundrc that i had picked up from here: > > # got from http://www.nabble.com/tascam-us122l-and-ccrma-td24036395.html > # thanks to Karsten > > # The usb_stream plugin configuration > > pcm.!usb_stream { > @args [ CARD ] > @args.CARD { > type string > default "0" > } > > type usb_stream > > card $CARD > } > > ctl.!usb_stream { > @args [ CARD ] > @args.CARD { > type string > default "0" > } > > type hw > > card $CARD > } > > i think the problem is that alsa/jack don't know where to look for > both the inputs and outputs (as midi works great). > unfortunately, i have little to no experience with this, and am not > sure how to proceed. > > it turns out that this card DOES use echi_hcd (i didn't unbind > uchi_hcd this time). > > (dmesg) > usb 1-5: new high speed USB device using ehci_hcd and address 3 > usb 1-5: config 1 interface 1 altsetting 1 bulk endpoint 0x83 has > invalid maxpacket 9 > usb 1-5: New USB device found, idVendor=0644, idProduct=8021 > usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > usb 1-5: Product: US-122 MKII > usb 1-5: Manufacturer: TASCAM > usb 1-5: SerialNumber: no serial number > > as you can see echi_hcd is being used and..... > > [ninez@ninez ~]$ ls /sys/bus/pci/drivers/ehci_hcd > 0000:00:1d.7 bind module new_id remove_id uevent unbind > > the card is found when you look for it! > > [ninez@ninez ~]$ cat /proc/asound/cards > 0 [Intel ]: HDA-Intel - HDA Intel > HDA Intel at 0xefffc000 irq 27 > 1 [US122L ]: USB US-122L - TASCAM US-122L > TASCAM US-122L (644:8021 if 0 at 001/003) > > when i start Qjackctl up: > > jackdmp 1.9.5 > Copyright 2001-2005 Paul Davis and others. > Copyright 2004-2009 Grame. > jackdmp comes with ABSOLUTELY NO WARRANTY > This is free software, and you are welcome to redistribute it > under certain conditions; see the file COPYING for details > JACK server starting in realtime mode with priority 89 > audio_reservation_init > Acquire audio card Audio0 > creating alsa driver ... hw:0|-|128|3|44100|0|0|nomon|swmeter|-|32bit > Using ALSA driver HDA-Intel running on card 0 - HDA Intel at > 0xefffc000 irq 27 *** using internal sound (bah!) > configuring for 44100Hz, period = 128 frames (2.9 ms), buffer = 3 periods > ALSA: final selected sample format for playback: 32bit integer little-endian > ALSA: use 3 periods for playback > Using port names patch v0.1 (07.04.2010) > port created: Midi-Through:midi/playback_1 > port created: Midi-Through:midi/capture_1 > port created: TASCAM-US-122L:midi/playback_1 > *** it uses the midi just fine (i tested it with Native > intruments, massive) > port created: TASCAM-US-122L:midi/capture_1 > 15:46:49.327 ALSA connection change. > 15:46:50.351 Server configuration saved to "/home/ninez/.jackdrc". > 15:46:50.352 Statistics reset. > 15:46:50.367 Client activated. > 15:46:50.369 JACK connection change. > 15:46:50.374 JACK connection graph change. > > if i set it to hw:1 jack can't start, nor does it matter if i am > duplex, playback(only) or capture(only).. > so i am convinced this driver can work, otherwise midi wouldn't work > at all. the problem is my configuration. > but i am not sure how to remedy this, any clues would help! (let's not > give up quite yet!) > > it's finding out how to tell it to use outputs and inputs properly. > > jordan > MIDI works because it is done by another driver. Follow these instructions to see if you can get the US122 MKII working like a US122L: http://www.premiumorange.com/la-page-web-of-phil/index.php?page=P030101#con… The interface is not hw:0 but usb_stream:1. Also the US122L works with both ehci-hcd and uhci-hcd, the US144 only works with uhci-hcd. Good luck, others tried it before and it didn't work. Greetings, Tobias

3 5

Re: [alsa-devel] Status of the Tascam US-122mkII???
by Daniel Mack 19 Jun '10

19 Jun '10

Hi, On Sat, Jun 19, 2010 at 02:30:03PM -0400, jordan johnston wrote: > On Sat, Jun 19, 2010 at 2:09 PM, Daniel Mack <daniel(a)caiaq.de> wrote: > > > (please don't remove any addresses from Cc:) > > im not sure that i follow what you mean here, can you explain??? Always use your email client's "reply-to-all" function, and do not just send replies to me. > *** no i did not modify the driver to match this, how do i do that??? Sorry, I didn't check properly. The driver clearly notes the vendor/product ID of your device, that's why it is probed but fails. This was added in commit 2b6f6c0d11 ("ALSA: snd-usb-us122l: add product IDs of US-122MKII and US-144MKII"). Obviously, this patch wasn't tested with real hardware (this is also what the commit log says), so it's no surprise it doesn't work for you. I copied the author, and I'd vote for reverting the patch until the driver is modified to actually support what it claims to do. > I set it to USB1.1 because i was under the impression that it will > not work with echi_hcd, > am i correct?? Well, according to the lsusb dump, the device is high-speed, so you shouldn't need any tricks. > my problem is that there really isn't any documentation that's > up-to-date for this unit, the newest info i could find > was a thread about the patches being submitted in December of last > year. but i figure by now that Zen should be up to date > with the changes made, so i am still in the dark about this unit's status.. Who is Zen? I think the answer to your question is quite simple but unfortunate: TASCAM changed the protocol of the device in a newer version, and the existing ALSA driver became incompatible with that. So there are only two possibilites to fix this: either TASCAM will send patches to the driver (which I think is unrealistic), or someone starts over and reverse-engineers the protocol in order to make the driver support it. As you happen to have the hardware - would you volunteer? :) > Do you have contact information for him?? i am not sure how to go > about the next steps you mention, > but i would be more than willing to do what i can, if i was explained > the process. > like i said before i am not a good programmer, but i am decent enough > with unix/linux and i do have XCode > for OSX - if that's what i need for tracing? Well, starting developing on the Linux kernel should be possible for you then, and help is much appreciated :) There's a lot of documentation around, and there is this and many other lists to get help on specific topics. Just read Documentation/SubmittingPatches before you send :) For tracing, you would either need a hardware analyzer (which you probaly don't have) or a software tool. For Windows, tools like http://www.usblyzer.com/ exist, but I never tried them myself. Maybe give that one a try and analyze which packets go over the bus. As there is no documentation, there is no other way than guessing what they're doing. This can be really time-consuming and frustrating, unfortunately. Good luck :) Daniel

2 1