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

[alsa-devel] [ASoc] TDM over one SSC channel on AT91 possible?
by Friedrich Lobenstock 24 Jun '11

24 Jun '11

Hello! The background: I'm just designing an ATMEL AT91RM9200 based board which got two TLV320AIC33 on board. It is either possible to hook up the two TLV320AIC33 to a separate SSC (synchronous serial control) channel each or use one SSC channel and configure it for TDM (time division multiplex) mode. There is already a driver for TLV320AIC14k/TLV320AIC2k in the development tree, so adding support for the TLV320AIC33 should be feasible. What I'm not sure about is the fact if ASOC is prepared for using channels, especially SSC, in TDM mode. Is the core ASOC structure prepared to handle that? Would we be better off instantiate one drive twice each time with different parameters for the SSC channel? Thanks for any feedback. -- MfG / Regards Friedrich Lobenstock _________________________________________________________ SCOTTY Group Austria GmbH a SCOTTY Group plc company, http://www.scottygroup.com/ _________________________________________________________

4 3

[alsa-devel] Altec Lansing FX5051 mixer
by Jeremy Nickurak 03 Apr '08

03 Apr '08

I recently purchased an Altec Lansing USB Surround speaker set. (It's a set of 5.1 speakers, with a built-in USB sound card). I've got about a week before the return policy expires and I'd have to return it. The mixer doesn't work at all w/linux kernel 2.6.22, everything is locked at 100% volume, which is pretty unhelpful, as it's the only way to adjust the volume. (no analog controls). Also, the digital control panel locks up when the speakers power up, further preventing any access to the volume controls. The device works out-of-the-box without any drivers under XP, so I have to so-far assume that alsa's usb-audio is missing something. Any thoughts as to what could be wrong? I'm more than happy to prod the device and submit any information I can extract about it, or even potentially opening the device up for remote access if a reputable developer is interested in examining it. -- Jeremy Nickurak -= Email/Jabber: atrus(a)rifetech.com =-

3 4

[alsa-devel] ALSA driver for Native Instruments sound hardware
by Daniel Mack 23 Mar '08

23 Mar '08

Hi, some months after the last posting, we finally managed to finish a new version of the ALSA driver for Native Instruments' external USB sound cards such as "Rig Kontrol 2", "Kore Kontroller", "Audio Kontrol 1" and "Audio 8 DJ". Compared to the last release, the following things were changed: - the streaming logic was completely reworked so that multiple substreams are handled correctly - a Linux input device layer was added to support the knobs, buttons and pedals on "Rig Kontrol 2" and "AudioKontrol 1" - workqueues were entirely removed from the code - most data structures are now allocated within one big struct to avoid multiple, smaller allocations - many more cleanups according to Clemens' reply on my last posting[1] The driver was properly tested with all the mentioned hardware on both record and playback channels. The patchset should apply to the current mecurial alsa-kernel tree. Please let me know what you think. Best regards, Daniel [1] http://article.gmane.org/gmane.linux.alsa.devel/34324/ Signed-off-by: Daniel Mack <daniel(a)caiaq.org> Signed-off-by: Karsten Wiese <fzu(a)wemgehoertderstaat.de>

4 10

[alsa-devel] underruns and strange code in pcm_rate.c (and patch)
by Stas Sergeev 01 Feb '08

01 Feb '08

Hi. I spent 4 week-ends debugging the constant underruns and lock-ups with the libao-based programs. Now I've finally tracked the problem to some strange code in pcm_rate.c, namely snd_pcm_rate_poll_descriptors(). I am not sure what was the reason behind altering the "avail_min" every time. Looks like some heuristic was intended, say "see what amount of fragment part was written now, and make sure that amount of free space will be available next time, after poll". Whatever, this code gives underruns. It can increase avail_min by almost period_size. libao sets avail_min==period_size, so we can end up with avail_min==period_size*2. libao sets buffer_size==stop_threshold==period_size*2. So we end up with avail_min~=stop_threshold, which gives underruns. Since I don't know how this code was indended to work, I just removed it, and everything works perfectly now (also had to patch libao to check the returned rate). The patch is attached, any comments? Signed-off-by: Stas Sergeev <stsp(a)aknet.ru>

7 47

[alsa-devel] [lennart@poettering.net: Status of ALSA "simple" mixer interface]
by Lennart Poettering 23 Dec '07

23 Dec '07

Hi! A few days ago I sent the attached emails to Takashi and filed a couple of bugs on the ALSA BTS. Takashi suggested to post these issues on the ML as well, to allow public discussion. So, here we go. The relevant bugs are: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3570 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3569 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3568 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3572 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3571 Lennart

5 36

[alsa-devel] [PATCH] PulseAudio plugin: report XRUN state back to application
by Lennart Poettering 22 Dec '07

22 Dec '07

Hi! Please consider merging this patch we ship in Fedora: http://cvs.fedoraproject.org/viewcvs/*checkout*/devel/alsa-plugins/1.0.14-s… It adds support to report back XRUN to the application if one happens. This is required to make some applications work on top of the pulse plugin. One being XMMS, which checks if a song finished to play by waiting for an XRUN (yes, I don't argue that XMMS shouldn't do that, but nonetheless it is a good thing if XRUNs are reported properly.) Now, this patch is a bit problematic, since it touches pcm->io.state which is not supposed to be touched by ioplug-based plugins -- according to the comments in ioplug. However, I saw no other way to fix this, and from judging the ioplug code overwriting the variable should be safe. Thus I decided to simply touch the variable but documented it in a comment. Alternatively, ioplug could be beefed up to properly handle XRUNs, but I thought this fix is simpler. Also reported on the ALSA BTS: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3579 Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

2 2

Re: [alsa-devel] asihpi driver -> kernel
by Takashi Iwai 20 Dec '07

20 Dec '07

Hi Eliot, [it seems that you Cc'ed to the old alsa-devel ML so the last one seemed missing.] At Tue, 16 Oct 2007 14:47:15 +1300, Eliot Blennerhassett wrote: > > Hi Takashi, > > still trying to move forward on this... > > Looking for "what is the first step" change to make in your opinion? The first step would be to get closer to linux kernel coding style. Namely, - get rid of C++ style function names, variables and field names (no hungarian!) - remove API wrappers Eventually, we may get rid of unneeded typedefs, too. Then, we can begin with simplifying the driver structure. Currently, asihpi and hpi are almost indepedent implementations. This makes life harder. > Takashi Iwai wrote: > > At Wed, 05 Sep 2007 13:00:35 +1200, > > Eliot Blennerhassett wrote: > >> Hi Takashi, > >> > >> I'd like to talk more about what you think is needed to get asihpi driver > >> ready for kernel tree. > >> > >> I think for now we should put aside cosmetic coding style changes (eg. comment > >> style, whitespace etc.) these are fixable with combination of automated tools > >> and some monkey work. > >> > >> So, lets start with the hard part. If we can't solve that there is no point in > >> cosmetics! > >> > >> A while ago you said "The specific problem I'm concerned is the "glue-code" > >> style in HPI driver. The OS-independent wrapper code is often disliked by > >> kernel maintainers. " > >> > >> Can you point to specific examples. Even better suggest how you think it > >> should be done better. Either way I need to consider how your concerns could > >> be addressed without breaking our codebase for other OSes etc. > >> > >> thanks and regards > > > > The problem is that the whole "wrapping" is superfluous when you > > concentrate on Linux driver. Merging into the linux kernel tree means > > that the driver would be dedicated to Linux. It's no longer your > > child, and it's no longer for every other OS. Thus, "common codebase" > > doesn't exist per se. > > > > For example, the whole definitions in hpios_linux_kernel.h should go > > away. The driver should use the native kernel API instead. > > Even this is not so hard, as it a mechanical process to replace wrapped > calls with linux native calls. OK, then it's fine. > > I know it's a very hard decision. Supporting other OSes is very > > important in most cases. OTOH, the slim-down is the best way to make > > the driver code maintainable for other people. Honestly, I find it > > also hard to maintain/debug the current ASIHPI code. It's too > > different from the normal codes, and understanding it alone takes too > > much energy before analyzing the problem. > > This is where I need more input, because to _me_ (of course) the code is > understandable. > > Is it the whole source or just parts that are hard. > E.g toplevel asihpi.c Ok/No? The code in asihpi.c is readable enough. But, other parts are different. The difficulty is that the driver structure isn't straight (apart from the coding style issues). We have an entry point for PCI driver _and_ indepdendent HPI initialization. This is already puzzling because HPI is also assigned to the corresponding PCI device. Also, the message union/struct is another stuff that is pretty hard to follow. Since we use no C++, union is often bad for readability. Could it be a bit simpler? > > The coding-style issues are similar problems. When C++-style codes > > appear in the tree of C-codes, they are strange. Simply so. It makes > > difficult to find the problematic part. "A buggy part looks buggy" -- > > it's the whole point of having a uniform coding style. > > Again, a mechanical process to change comments and style etc. Then it's fine with me. Let's try and see the progress. > > These problems (different from others) make it impossible to merge to > > the upstream tree, so far. > > > > > > > >> Eliot > >> BTW I'm happy to conduct this discussion publically on alsa-devel, some other > >> people might learn something too... > > > > I think it's a good thing, too. Feel free to add alsa-devel to Cc in > > the next reply with citation. > > > >> For reference here is the source tree diagram. > >> > >> asihpi.c alsa driver toplevel > >> | > >> hpifunc.c message/response pack/unpack > >> | > >> hpimsgx.c hpi stream ownership, backend selection, some init > >> | > >> hpi6205.c hpi6000.c hpi4000.c card family drivers > >> | > >> hpicmn.c, hpios_linux.c hpidspcd.c hpidebug.c library code > >> > >> hpimod.c probing, HPI ioctl > >> > > > > > > thanks, > > > > Takashi thanks, Takashi

2 13

[alsa-devel] rate plugin issue
by Takashi Iwai 19 Dec '07

19 Dec '07

Hi, I committed your patch now on HG tree, as it's likely OK from the possible breakage on other apps, too. Anyway, I swear that I'll never read any mails during my next vacation. That was so exhausting to be dragged to a lengthy discussion for band-aiding a badly designed compoment... :) Takashi

3 11

[alsa-devel] Altec Lansing FX5051 USB Speakers
by Jeremy Nickurak 15 Dec '07

15 Dec '07

Some number of months ago I posted a request here for any suggestions in getting a set of USB speakers from Altec Lansing, model# FX5051, working with ALSA. I wasn't able to follow up in detail at the time, so I'm hoping try again. They're a set of 5.1 speakers with a built in USB sound card. Sound does appear to work, but the mixer is locked at 100%. There is no analog manual mixer, and the digital control dial exhibits the same problem as alsamixer, so I have to find a way to adjust the usb device's mixer volume in order to make the speakers usable. The speakers work fine in Windows XP, without installing any drivers, so it would seem that this device is operating based on some standard. In windows, adjusting the mixer via the digital control dial, or via the windows mixer control both result in the LED display moving in sync to indicate the new volume setting. In alsa, adjusting the digital control dial doesn't appear to have any effect, other then waking the LED display from its low-light mode. Attempting to adjust volume from alsamixer likewise wakes the display from low-light mode, but also fails to significantly change the mixer setting. When I say significantly, I mean that the mixer flips between about 98% and 100%, when using the Up/Down keys (or PgUp or PgDown). End appears to drop the volume to 0%, but Home doesn't restore it. Pressing the device's 'Power' button also behaves strangely. I can turn the device off, but it is turned back on shortly afterward. No usb connect/disconnect events appear here, instead, the power button seems to function more like a mute. amixer -c 2 contents yields: atrus@kedri:~$ amixer -c 2 contents numid=3,iface=MIXER,name='Tone Control - Bass' ; type=INTEGER,access=rw------,values=1,min=0,max=10,step=0 : values=1 numid=4,iface=MIXER,name='Tone Control - Treble' ; type=INTEGER,access=rw------,values=1,min=0,max=10,step=0 : values=3 numid=1,iface=MIXER,name='PCM Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=2,iface=MIXER,name='PCM Playback Volume' ; type=INTEGER,access=rw---R--,values=2,min=0,max=49,step=0 : values=48,48 | dBscale-min=-49.00dB,step=1.00dB,mute=0 I'm attaching the contents of 'lsusb -v'. Any suggestions would be appreciated, and any requests for further information about this device will be accomodated ASAP. Thanks in advance. -- Jeremy Nickurak -= Email/Jabber: atrus(a)rifetech.com =-

1 1

Re: [alsa-devel] [Pkg-alsa-devel] Bug#438118: alsa-utils: aplay non-blocking mode isn't working
by Elimar Riesebieter 14 Dec '07

14 Dec '07

forwarded 438118 alsa-devel(a)alsa-project.org stop Hi all, can one please have a lokk at this? aplay -N isn't working for the OP. On Thu, 16 Aug 2007 the mental interface of Anders Boström told: > >>>>> "ER" == Elimar Riesebieter <riesebie(a)lxtec.de> writes: > > >> strace aplay -N : > >> > >> ... > >> open("/usr/lib/alsa-lib/libasound_module_rate_speexrate.so", O_RDONLY) = -1 ENOENT (No such file or directory) > > ER> This file is provided by > ER> libasound2-plugins: /usr/lib/alsa-lib/libasound_module_rate_speexrate.so > > ER> Please install libasound2-plugins and try again. > > Thanks for the suggestion. > > Unfortunately, it didn't solve my problem, no sound when non-blocking > mode is used. New strace: > > strace aplay -N : > ... > open("/usr/lib/alsa-lib/libasound_module_rate_speexrate.so", O_RDONLY) = 5 > read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\22\0"..., 832) = 832 > fstat(5, {st_mode=S_IFREG|0644, st_size=20848, ...}) = 0 > mmap(NULL, 2116136, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0x2b9f792fe000 > mprotect(0x2b9f79302000, 2097152, PROT_NONE) = 0 > mmap(0x2b9f79502000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x4000) = 0x2b9f79502000 > close(5) = 0 > ioctl(4, 0xc2604110, 0x7fff3269dec0) = 0 > ioctl(4, 0xc2604110, 0x7fff3269dec0) = 0 > ioctl(4, 0xc2604110, 0x7fff3269de00) = 0 > ioctl(4, 0xc2604110, 0x7fff3269de00) = 0 > ioctl(4, 0xc2604110, 0x7fff3269ddd0) = 0 > ioctl(4, 0xc2604110, 0x7fff3269ddc0) = 0 > ioctl(4, 0xc2604111, 0x7fff3269ddc0) = 0 > ioctl(4, 0xc0884113, 0x7fff3269dd10) = 0 > ioctl(4, 0x80184132, 0x7fff3269dc70) = 0 > mmap(NULL, 49152, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0x2b9f79503000 > ioctl(4, 0xc0884113, 0x624e88) = 0 > ioctl(4, 0x4140, 0) = 0 > ioctl(4, 0xc0884113, 0x624e88) = 0 > read(3, "\377eO\333\337\370\344}\335_\377\330^l\356\361`j\336_l"..., 1001) = 1001 > read(3, "n{u^\342zl~e~_[\365_y\362_\363\350\337n[\347nmi`\367y\344"..., 604) = 604 > ioctl(4, 0x4144, 0x2b9f785d8000) = -1 EAGAIN (Resource temporarily unavailable) > close(3) = 0 > ioctl(4, 0x4143, 0x3) = 0 > munmap(0x2b9f79503000, 49152) = 0 > ioctl(4, 0x4112, 0) = 0 > close(4) = 0 > munmap(0x2b9f785d7000, 4096) = 0 > munmap(0x2b9f785d8000, 4096) = 0 > munmap(0x2b9f792fe000, 2116136) = 0 > exit_group(0) = ? I have no idea, so forwarded to alsa-dev then. THX in advance Elimar -- Experience is something you don't get until just after you need it!

5 8