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

[alsa-devel] New hardware report
by Alain DANGER 24 Oct '07

24 Oct '07

Hi. I managed to get the sound work with ALSA on the following MB : Shuttle AK32VN. OS : Kubuntu 7.10. Regards. Alain Danger

2 1

[alsa-devel] mplayer plays video twice as fast with Alsa than with OSS
by Timur Tabi 24 Oct '07

24 Oct '07

Hi, I wrote an Alsa device driver that supposedly works with the OSS emulation, but one of our customers is reporting that mplayer with the "-ao oss" option plays video twice at double speed. If they select "-ao alsa" instead, then it plays normally. Is this a known problem?

2 1

Re: [alsa-devel] [Jackit-devel] RME HDSPe floating point question
by Didier Villevalois 24 Oct '07

24 Oct '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, (Cross-posting my report - last time i do this) Great news (almost for me in anyways). RME HDSPe PCI *works as is* with the current driver. Firmware uploads as well. I had nothing to do to make it work! (I think the ExpressCard should work as well...) Maybe the alsa-project wiki page can be updated. Little by little in the next weeks, I will delve into the driver's code to identify parts that needs to be enhanced in order to take profit of the 32bit floating point format that the HDSPe card can provide. When ready, I'll contact RME to request them for informations about the activation of this mode. Didier. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHHcG6VE1mALQL3JsRAjeZAKCJqicClHgy1UDc1YvAywuw1FokyQCeJO2d BhWpkxL8xLGxKB3zmbWFQpk= =wpbm -----END PGP SIGNATURE-----

2 3

[alsa-devel] [RFC] ALSA scenario API
by Liam Girdwood 23 Oct '07

23 Oct '07

A little late with this but "better late than never".....I did promise a few people that I would post what was imho needed for ALSA scenarios. Also, apologies for cross posting, but it some of this probably applies to both lists... ALSA probably needs functionality to define and set audio usage scenarios. A scenario is simply a list of sound card mixer settings for a given use case. This is quite important for mobile devices (e.g. Smartphones, GPS, PDA, etc) with complex audio routing and power requirements. Some example scenarios could be :- "HiFi Headphone Playback" "HiFi Speaker Playback" "Handset Phone Call" "Headset Phone Call" etc... Scenarios are changed atm by either manually setting each control (e.g. using alsamixer or alsa-lib in apps) or by using alsactl to restore a scenario. The above two methods are not very portable between devices and applications. We would ideally like to just say "set Phone Call Handset" for a regular handset phone call or "set HiFi Headphones" for MP3 playback. ALSA also needs to have functionality to alias mixer controls. This would allow a single master volume/mute control to be exposed to user space and have it aliased to different hardware controls based upon the current scenario. e.g. Many mobile devices have different physical volume controls for speaker and headphones. This makes it somewhat difficult for user space apps to change the correct volume (without being bound to the hardware). We would like to be able to just say "set volume to 0dB" and have the alias take care of the correct physical CODEC mixer for the current scenario. Proposal: ======== 1. Add some new scenario functions to (s)alsa-lib. e.g. snd_scenario_set(); snd_scenario_get(); snd_scenario_list(); _set() would set the scenario e.g. snd_scenario_set(card, SND_VOICE_CALL_HANDSET); We would need to have a list of standard scenarios so that applications could be more portable. Vendor scenario's should also be supported. _get() would return the current scenario. _list() would return a list of supported scenarios for the given device. 2. Add some new mixer alias functions to set/get the current "master" volume/mute. e.g. snd_kcontrol *snd_scenario_volume_set(card, type, volume); snd_kcontrol *snd_scenario_switch_set(card, type, switch); where type is playback, capture, sidetone, bypass, etc This would set the volume for the current scenario and would guarantee always to get/set the _correct_ volume/switch. 3. Add a new function to return the active PCM for a given scenario. e.g. snd_scenario_get_pcm(card, scenario); Would return the given PCM for a particular scenario. i.e. the WM9713 driver has PCM 0.0 for high quality (higher power) audio (MP3), PCM 0.1 for lower power voice and PCM 0.2 for lowest power and quality system sounds. Note: scenarios may need to be more tightly bound to PCM's rather than cards. 4. Define a file format to represent each scenario. Probably base this upon alsactl's format as alsamixer could be used to quickly generate good settings and then save them with alsactl. Alias, scenario names and PCM would need to be added later somehow. 5. (Optional) Allow scenarios to define active kcontrols. This would allow tools like alsamixer to only display mixer controls for the given scenario. Controls that don't effect the scenario would not be rendered. (similar to alsamixers Playback|Capture|All tab) 6. (OHM list) Add input driver (or similar) for sound card user events. We need to be able to send events like "Headphone Jack Insertion", "Mic Jack Insertion", etc to user space. This would allow changing of scenario and power configuration depending on policy and configuration. Just my 2p Unfortunately I'm not in a position to implement any of this functionality. However, it's probably useful to folks working on mobile devices. Maybe a good project for Google SoC. HTH Liam

3 4

Re: [alsa-devel] [PATCH] asihpi checkpatch clean plus control name refactor
by Takashi Iwai 23 Oct '07

23 Oct '07

At Tue, 23 Oct 2007 16:48:20 +1300, Eliot Blennerhassett wrote: > > checkpatch.pl --no-tree now reports no errors on asihpi.c > Redo control names to be strings only (not using control index) > > Signed-off-by: Eliot Blennerhassett <linux(a)audioscience.com> Thanks, applied to HG tree now. (BTW, I couldn't access the ftp. Anon-ftp isn't allowed?) Takashi

1 0

[alsa-devel] [PATCH] asihpi checkpatch clean plus control name refactor
by Eliot Blennerhassett 23 Oct '07

23 Oct '07

checkpatch.pl --no-tree now reports no errors on asihpi.c Redo control names to be strings only (not using control index) Signed-off-by: Eliot Blennerhassett <linux(a)audioscience.com> Patch here; (70k) ftp://ftp.audioscience.com/internet/download/beta/asihpi_checkpatch_clean.d… regards Eliot

1 0

[alsa-devel] USB device gives wrong data?
by william estrada 23 Oct '07

23 Oct '07

Hi group, I think I have found a problem with the USB sound driver? It appears that the current drive returns a x'81' for silence but it should be a x'7f'. When I use my laptop's sound device and record without a mic, I get a file full of x'7f's. If I do the same with my cheap-o USB device I get a file full of x'81's. The sound quality from the laptop is unacceptable, so that is way I want to use the USB device. I have written a recording program that I have a 'silence' filter that filters out segments of dead air. It works with the laptop's sound device but not the USB device. The filter works by remove x'7f's after allowing a selectable amount. I get the results using arecord which does not have the filtering. The USB device is a C -Media Electronics, Inc. I am running FC6. > [root@laptop ~]# lsmod |grep snd > snd_usb_audio 81985 0 > snd_usb_lib 21057 1 snd_usb_audio > snd_rawmidi 28481 1 snd_usb_lib > snd_hwdep 13637 1 snd_usb_audio > snd_ali5451 27853 1 > snd_ac97_codec 99813 1 snd_ali5451 > snd_ac97_bus 6593 1 snd_ac97_codec > snd_seq_dummy 8133 0 > snd_seq_oss 37057 0 > snd_seq_midi_event 11841 1 snd_seq_oss > snd_seq 57009 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event > snd_seq_device 12365 4 snd_rawmidi,snd_seq_dummy,snd_seq_oss,snd_seq > snd_pcm_oss 46433 0 > snd_mixer_oss 20545 1 snd_pcm_oss > snd_pcm 80965 4 snd_usb_audio,snd_ali5451,snd_ac97_codec,snd_pcm_oss > snd_timer 26693 2 snd_seq,snd_pcm > snd 58181 140 snd_usb_audio,snd_rawmidi,snd_hwdep,snd_ali5451,snd_ac97_codec,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer > soundcore 12193 1 snd > snd_page_alloc 14281 1 snd_pcm Where do I report this 'bug' or how do I fix it? Thanks for your time. Sorry for the multiple posting, not sure where is should have gone. -- William Estrada MrUmunhum(a)popdial.com Mt-Umunhum-Wireless.net ( http://Mt-Umunhum-Wireless.net ) Ymessenger: MrUmunhum

3 3

Re: [alsa-devel] WM9712 monoout
by Mike Rapoport 22 Oct '07

22 Oct '07

Liam Girdwood wrote: > On Sun, 2007-10-21 at 09:35 +0200, Mike Rapoport wrote: >> Hello, >> >> I'm trying to enable phone on a board with WM9715 codec. >> I have not found a control responsible for mute/unmute the MONOUT. >> My question is whether I should add this control as platform specific control, >> or it would be correct to patch sound/soc/codecs/wm9712.c? > > It should probably go in the codec driver. It looks like an omission. > >> Also, "Mono Playback Volume" control is not inverted, which seems to be a bug. >> > > Could you send a patch ? Sure. A also found that treble and bass need to be inverted. > Many Thanks > > Liam > Signed-off-by: Mike Rapoport <mike(a)compulab.co.il> sound/soc/codecs/wm9712.c | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/sound/soc/codecs/wm9712.c b/sound/soc/codecs/wm9712.c index 986b5d5..427cb61 100644 --- a/sound/soc/codecs/wm9712.c +++ b/sound/soc/codecs/wm9712.c @@ -102,7 +102,8 @@ SOC_SINGLE("Speaker Playback ZC Switch", AC97_MASTER, 7, 1, 0), SOC_SINGLE("Speaker Playback Invert Switch", AC97_MASTER, 6, 1, 0), SOC_SINGLE("Headphone Playback ZC Switch", AC97_HEADPHONE, 7, 1, 0), SOC_SINGLE("Mono Playback ZC Switch", AC97_MASTER_MONO, 7, 1, 0), -SOC_SINGLE("Mono Playback Volume", AC97_MASTER_MONO, 0, 31, 0), +SOC_SINGLE("Mono Playback Volume", AC97_MASTER_MONO, 0, 31, 1), +SOC_SINGLE("Mono Playback Switch", AC97_MASTER_MONO, 15, 1, 1), SOC_SINGLE("ALC Target Volume", AC97_CODEC_CLASS_REV, 12, 15, 0), SOC_SINGLE("ALC Hold Time", AC97_CODEC_CLASS_REV, 8, 15, 0), @@ -145,8 +146,8 @@ SOC_ENUM("Bass Control", wm9712_enum[5]), SOC_SINGLE("Bass Cut-off Switch", AC97_MASTER_TONE, 12, 1, 1), SOC_SINGLE("Tone Cut-off Switch", AC97_MASTER_TONE, 4, 1, 1), SOC_SINGLE("Playback Attenuate (-6dB) Switch", AC97_MASTER_TONE, 6, 1, 0), -SOC_SINGLE("Bass Volume", AC97_MASTER_TONE, 8, 15, 0), -SOC_SINGLE("Treble Volume", AC97_MASTER_TONE, 0, 15, 0), +SOC_SINGLE("Bass Volume", AC97_MASTER_TONE, 8, 15, 1), +SOC_SINGLE("Treble Volume", AC97_MASTER_TONE, 0, 15, 1), SOC_SINGLE("Capture ADC Switch", AC97_REC_GAIN, 15, 1, 1), SOC_ENUM("Capture Volume Steps", wm9712_enum[6]),

2 3

[alsa-devel] snd-pcsp doesn't accept the index parameter
by Alexander E. Patrakov 22 Oct '07

22 Oct '07

It is impossible to put pcsp at a stable index without the trivial patch below. Signed-Off-By: Alexander E. Patrakov <patrakov(a)ums.usu.ru> --- pcsp.c +++ pcsp.c @@ -27,6 +27,8 @@ static char *id = SNDRV_DEFAULT_STR1; /* ID for this card */ static int enable = SNDRV_DEFAULT_ENABLE1; /* Enable this card */ +module_param(index, int, 0444); +MODULE_PARM_DESC(index, "Index value for pcsp soundcard."); module_param(id, charp, 0444); MODULE_PARM_DESC(id, "ID string for pcsp soundcard."); module_param(enable, bool, 0444); -- Alexander E. Patrakov

2 1

[alsa-devel] [PATCH] hda: STAC9228 updated DMUX nid.
by Matthew Ranostay 22 Oct '07

22 Oct '07

Changed the dmux for STAC9228 from ADC1MUX to ADC0MUX to avoid confusion. --- Signed-off-by: Matthew Ranostay <mranostay(a)embeddedalley.com> diff -r 7cf5e23f804e pci/hda/patch_sigmatel.c --- a/pci/hda/patch_sigmatel.c Fri Oct 19 08:23:00 2007 +0200 +++ b/pci/hda/patch_sigmatel.c Fri Oct 19 13:47:35 2007 -0400 @@ -2777,7 +2777,7 @@ static int patch_stac927x(struct hda_cod case 0x10280209: /* STAC 9228 */ spec->dmic_nids = stac927x_dmic_nids; spec->num_dmics = STAC927X_NUM_DMICS; - spec->dmux_nid = 0x1c; + spec->dmux_nid = 0x1b; break; default: spec->num_dmics = 0;

2 1