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

[alsa-devel] [PATCH] RME 9632 fix at 192kHz
by Remy Bruno 22 Feb '08

22 Feb '08

Hello, I realized that one of my hdsp patches was not included in the hg tree, so I guess I forgot to submit it, sorry for submitting only now. Description: The bits indicating SPDIF frequency in the status register are not the same for the 9632 than for the other cards, because it also supports 192kHz. A specific bitmask has thus been added (used in hdsp_spdif_sample_rate()). The 9632 does not seem to report external sample rates greater than 96kHz. In this case, the best seems to report spdif rate when autosync reference is spdif. This also required to move function hdsp_spdif_sample_rate(). Signed-off-by: Remy Bruno <remy.bruno(a)trinnov.com> Regards, Remy

2 1

[alsa-devel] [PATCH] alsa-lib: issues in snd_seq_change_bit and some enhancements
by Aldrin Martoq 22 Feb '08

22 Feb '08

Hello hackers, I found two issues in sequencer part of alsa-lib while working with the python binding: 1) snd_seq_change_bit is not working as expected. 2) There is no sane way to clear the event_filter of snd_seq_client_info_t structure. Because the structure is opaque, we cannot memset to zero because the user doesn't know the size of the bitmap. The first attached patch is a demo of both issues. For 1) please apply snd_seq_change_bit.txt patch. For 2) I propose to clear the bitmap if NULL is passed, see snd_seq_client_info_set_event_filter.txt patch. Also, I think it makes no sense that the bitmap is returned or expected to be given in both snd_seq_client_info_{set,get}_event_filter; the client_info structure is opaque and the alsa-lib user can't/shouldn't known the bitmap size. The only sane way is to use the middle interface function snd_seq_set_client_event_filter(), but it only can be used for an opened sequencer's client_info. So, the last patch is a proposal for changing this: - mark as deprecated both snd_seq_client_info_{set,get}_event_filter - snd_seq_client_info_event_filter_clear() clears the event_filter - snd_seq_client_info_event_filter_add() add an event to the event filter - snd_seq_client_info_event_filter_del() removes an event from the event filter - snd_seq_client_info_event_filter_check() test if an event is present in the filtering Any comments? Thanks! -- Aldrin Martoq <amartoq(a)dcc.uchile.cl>

3 5

[alsa-devel] ASoC - Output widgets
by Alexandre BOUIN 22 Feb '08

22 Feb '08

Hi list, Using ASoC layer, I'd like to perform this example behaviour with my widgets : - 1 output mixer MIXOUT is connected to 2 outputs OUT1 and OUT2 - OUT1 and OUT2 can be powered independently This seems easy, but atm while one is powered, the other is powered too. Does someone have already made this widget behavior ? Regards, Alex.

1 0

[alsa-devel] Strange (HW?) bug with RME9632 + AO4S + Mobo DG33BU
by Remy Bruno 22 Feb '08

22 Feb '08

Hi, I came across a quite strange bug using the RME 9632 with an intel motherboard DG33BU, whose symptom is random xruns. Conditions: - Sound card = RME 9632. I tried several ones (recent and older ones), so this is not due to a defective card - AI4S/AO4S (daughter boards) pluged. The bug does not happen without these. I also tried several ones. - Sample rate does not matter (48kHz or 96kHz for example) - Last alsa driver/lib (from HG tree) - Linux kernel 2.6.23.9 - DG33BU motherboard. For example, on an Asus M2NPV-VM with the same cards/alsa/kernel, the bug does not happen. - And the most strange condition: send non-null samples to channels 1&3 or channels 2&4 of the daughter board (ie channels 13&15 or 14&16 at 48kHz). The bug does not happen if you send sound on channels 1&2 only, or 1 only, or 3 only for example, but it happens if you send on both 1&3. By analyzing what happens, I found the reason for the xrun. In the conditions of the bug, from time to time (say about 1 time over 1000), the memory space of the card (called "iobase" in the hdsp driver) is incorrectly read. The value 0xFFFFFFFF is read for any register instead of the correct values. I confirmed this behavior with the following experiment: - I wrote a programm permanently reading the memory space of the card, in an active loop, by mmap()ing /sys/bus/pci/devices/<my_card>/resource0, reading the first word, and reporting when 0xFFFFFFFF is read (BTW, this first register corresponds to the card status, and the value 0xFFFFFFFF is not a possible status value of the card from what I saw --- or at least this value is highly unlikely) This program effectively reports some 0xff-reads when the above conditions are met (ie when non-null samples are sent to channel 1&3 of AO4S). As I said before, not all reads give 0xFF, only some of them (but of course, this is enough to get problems!). As soon as the above conditions are not met (for example, outputing true silence on the AO4S), the program stops reporting problems. - To make sure the bug is not due to an alsa driver/library or program bug, I wanted to write non-null samples directly to the shared memory region without using snd_pcm_writeX(). In order to do so, I modified the code displaying /proc/asound/card0/hdsp in order to get the physical address of the playback buffer in addition to the virtual address already given. And then, by mmap()ing /dev/mem at the right offset, I got the possibility to write non-null values while the card is running. The effect is the same: while the alsa driver writes zeros, if I "overload" the buffer with non-null values at offset corresponding to channels 1&3 of the AO4S, I get several bad reads with my watching program (of course, the bad reads stop quickly because the alsa drivers continue to write zeros thus overwriting my non-null values and thus the bug conditions are not met any longer) I don't know exactly who is to be blamed here, because the card with the same driver/kernel on another motherboard works perfectly, and, indeed, no 0xFFFFFFFF reads are detected in this case. Needless to say, I tried several DG33BU mobos, several slots, several re-plugs of the PCI card, with the same behaviour. Maybe this can be due to some kind of PCI conflict? Anyway, the RME card is the only PCI/PCI-express card on the mobo. For now, the fix is truly wonderful: in hdsp_read(), keep on reading while 0xFFFFFFFF is read... With a maximum of times of course (I set 10). If the "true" value is not 0xFFFFFFFF, then the true value will be read at least once and so returned (I never got 10 consecutive times 0xFFFFFFFF, even not 2), and if the "true" value is 0xFFFFFFFF, then the only side effect of the patch is that the register will be read 10 times instead of 1. I don't think this can do any harm in any case. Anyway, there should be a competition for the most awful bugfix, I'm sure this one could win :-) So this hack fixes the software-visible part of the problem, but the punctual disparition of the IO space of the card is still there. For example, I don't know what happens as far as writing is concerned! Maybe some writes to registers of the card are ignored? I did not really investigate this, but I checked that there are no glitches in the sound (by checking that a sine is never distorted during a whole night), contrary to what happened without the fix. I join the patch corresponding to this hack, I'm not sure if it should be included in the main tree!... However, it may be usefull (it is for me anyway), because you can't use the AO4S card without it. I would be interested to know if other people had the same problem with this motherboard, or another one. Of course, I would also be interested if someone has got an idea about the reason for this strange behaviour. I will send an email to RME about this problem. Best regards, Remy Bruno

1 0

[alsa-devel] handling of dmix and non-dmix in the same configuration file
by Mike Frysinger 22 Feb '08

22 Feb '08

on the Blackfin processor, we have an "almost-but-not-quite" AC97 interface (called a "SPORT"). the trouble is that we can hook up AC97 codecs, but in order to properly communicate with codecs, we need to repacketize the communication between the higher alsa layers and the actual SPORT. great ... but now we want to support dmix/dsnoop. the overhead for dmix vs non-dmix is such that we make it optional. if the user does not need software mixing, they can disable this overhead. this leads to two (incompatible) alsa config files (in this case, for the AD1980 codec). we're wondering if it's possible to have the right settings selected on the fly some how during runtime rather than having to select one file or the other. the dmix config: AD1980.pcm.default { @args [ CARD ] @args.CARD { type string } type asym playback.pcm { type plug slave.pcm { @func concat strings [ "dmix:CARD=" $CARD ] } } capture.pcm { type plug slave.pcm { @func concat strings [ "dsnoop:CARD=" $CARD ] } } } the non-dmix config: AD1980.pcm.default { type plug slave { pcm { type mmap_emul slave { pcm { type hw card 0 format S16_LE rate 48000 channels 2 sync_ptr_ioctl 1 } } } } } -mike

2 1

Re: [alsa-devel] HDA: no sound in headphone-out caused by commit f889fa91ad47e (2.6.25-rc1 regression)
by Rene Dohmen 22 Feb '08

22 Feb '08

Thnx for you quick reply De sound of the line out is working but quality is poor and the volume is very low. I didn't have it working with other versions of ALSA. Tested with 1.0.14, then started reading, lots of suggestions stated that the problem would be solved in 1.0.15, so i compiled 1.0.16. De device i 'm using is supplied by tangent ( http://www.tangent.com/t_all_in_one_LCDPC/vita_8000s.htm) its an all in one solution with touchscreen and speakers integrated in one small cabinet. alsa-info.sh script output uploaded: http://pastebin.ca/913865 I wasn't aware of the fact that I communicated directly: I found the discussion in google groups: and just hitted reply :-) So sorry for that. I now subscribed myself to the ML Regards, Rene On Fri, Feb 22, 2008 at 8:09 AM, Takashi Iwai <tiwai(a)suse.de> wrote: > At Thu, 21 Feb 2008 18:56:30 -0800 (PST), > acidjunk(a)gmail.com wrote: > > > > Hi, > > I have exactly the same problem with my sound device: > > hda_codec: Unknown model for ALC262: trying auto-probe > > lspci output: 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 > > Family) High Definition Audio Controller (rev 01) from BIOS. > > > > I'm using alsa 1.0.16 compiled form source under ubuntu gutsy. I tried > > hardy but is has the same results > > > > The headphone output is working (not very loud, but usable), but the > > front speakers are not working. Did the patches solve the speaker > > issue? and how do I apply them (I am new to the patching technique). > > Please don't mix up. It is a totally different problem since your > machine has another codec (and even 1.0.16 doesn't work). The patch > cannot solve your problem. Save your time. > > Has any version of ALSA driver ever worked properly? If yes, we can > check the difference. > > If not, we need to track down the problem more deeply. First of all, > give more detailed hardware information: what is your laptop (or > desktop) vendor, model, etc. Try different model options. And the > output of alsa-info.sh -- it's vital information. > > Last but not least, don't forget to add alsa-devel ML to Cc in your > next reply. This isn't a kind of thing to be communicated privately > at all. > > > thanks, > > Takashi >

1 0

[alsa-devel] Alsa Driver Puzzlement
by Benson Dong 22 Feb '08

22 Feb '08

Hi all, What's the relationship between alsa driver and low-level audio hardware driver such as uda1341 driver?Is Alsa driver a individual module or cooperating with uda1341 dirver?If they co-work ,what's the interface between them? Anyone who knows please tell me? Thank in advance! Best, Benson _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

1 0

[alsa-devel] Device name and hw configuration
by Emmanuel Milou 21 Feb '08

21 Feb '08

Hi all, I am developping a softphone based on alsa. Does the device 'default' take in consideration the hardware parameters I set, like buffer size and period size? If not, should I play with the software parameters to improve the sound quality? Thanks Manu

1 0

[alsa-devel] [0/4] Convert PXA AC97 to use clock API
by Mark Brown 21 Feb '08

21 Feb '08

This patch series adds support for AC97 clocks on the PXA27xx and PXA3xx and converts both SoC and non-SoC pxa2xx-ac97 drivers to use the clock API rather than pxa_set_cken(). Since the ALSA changes require the changes to the ARM platform code it probably makes sense for them to be merged through ARM rather than ALSA.

4 15

[alsa-devel] [PATCH] hda: STAC927x analog mic
by Matthew Ranostay 21 Feb '08

21 Feb '08

Some laptops have a internal analog microphone that is not setup by the BIOS. Signed-off-by: Matthew Ranostay <mranostay(a)embeddedalley.com> --- diff -r 6b53fa114faa pci/hda/patch_sigmatel.c --- a/pci/hda/patch_sigmatel.c Tue Feb 19 15:03:57 2008 +0100 +++ b/pci/hda/patch_sigmatel.c Wed Feb 20 17:11:51 2008 -0500 @@ -3629,6 +3629,8 @@ static int patch_stac927x(struct hda_cod spec->mixer = stac927x_mixer; break; case STAC_DELL_BIOS: + /* configure the analog microphone on some laptops */ + stac92xx_set_config_reg(codec, 0x0c, 0x90a79130); /* correct the front output jack as a hp out */ stac92xx_set_config_reg(codec, 0x0f, 0x02270110); /* correct the front input jack as a mic */

2 2