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

[alsa-devel] period_size and .asoundrc
by Canella Matteo 26 May '09

26 May '09

Hi everybody, I'm writing a little software that play a tone on a pcm device. In the hw param initialization I'm hardcoding the "periods" and "period_size" values: unsigned int periods = 4; if (snd_pcm_hw_params_set_periods_near(buzzer_device.pcm_handle, buzzer_device.hwparams, &periods, 0) < 0) { fprintf(stderr, "Error setting periods.\n"); return 1; } ///* set the period time */ period_size = 8192; err = snd_pcm_hw_params_set_period_size_near(buzzer_device.pcm_handle, buzzer_device.hwparams, &period_size, 0); if (err < 0) { printf("Unable to get period size for playback: %s\n", snd_strerror(err)); return err; } I'd like to read this parameter form the .asoundrc file, so I'm wondering if there were API that does this task. Thanks Matteo Canella

2 1

[alsa-devel] 2.6.30: xruns caused by "ALSA: pcm - Safer boundary checks"
by Chuck Ebbert 26 May '09

26 May '09

Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=498858 To reproduce, pause a video in mplayer and then hit play: ALSA sound/core/pcm_lib.c:263: hda_codec: hw_ptr skipping! [Q] (pos=11263, delta=17400, period=1024, jdelta=21/362/0) ALSA sound/core/pcm_lib.c:337: hda_codec: hw_ptr skipping! (pos=11730, delta=1490, period=1024, jdelta=10/31) ALSA sound/core/pcm_lib.c:337: hda_codec: hw_ptr skipping! (pos=11734, delta=1494, period=1024, jdelta=10/31) ALSA sound/core/pcm_lib.c:337: hda_codec: hw_ptr skipping! (pos=11734, delta=1494, period=1024, jdelta=10/31) ALSA sound/core/pcm_lib.c:337: hda_codec: hw_ptr skipping! (pos=11735, delta=1495, period=1024, jdelta=10/31) ALSA sound/core/pcm_lib.c:263: hda_codec: hw_ptr skipping! [Q] (pos=12287, delta=2047, period=1024, jdelta=21/42/0) ALSA sound/core/pcm_lib.c:337: hda_codec: hw_ptr skipping! (pos=12449, delta=2209, period=1024, jdelta=4/46)

5 13

[alsa-devel] spdif/iec958 outputs at VT1708S not recognized
by Sentinel 26 May '09

26 May '09

I tried using the snapshot because I was having the same problem as Peter was. No spdif out on my vt1708s. Unfortunately for me my build didn't go quite as well, for some reason I had 2 undefined which make the snd.ko fail to load. Is there something that I'm missing? I am running slamd64 distro current, with the latest kernel along with the alsa kernel patch "2.6.29.4-rt15". Please help. Building modules, stage 2. MODPOST 131 modules WARNING: "register_sound_special_device" [/usr/src/alsa-driver/acore/snd.ko] undefined! WARNING: "unregister_sound_special" [/usr/src/alsa-driver/acore/snd.ko] undefined! make[1]: Leaving directory `/usr/src/linux-2.6.29.4' utils/link-modules /usr/src/alsa-driver

1 0

Re: [alsa-devel] Help on writing an ALSA ASoC Driver for WM8985
by Leung Chi Tat 26 May '09

26 May '09

Mark, I got it. Once we set those volume update bits in wm8990_init(), those bits in the wm8985 register cache array, wm8985_reg[], will then be set too. So, whenever we write a new value to a volume register, wm8985_write() will then write the new value to the volume register and update the corresponding volume update bit also. This is the trick. A Great Idea! Thank you so much! Chitat On Mon, May 25, 2009 at 08:47:31PM +0800, Leung Chi Tat wrote: > I'm right now studying the driver code for wm8980 codec (from the main > trunk of linux-2.6-asoc) as it seems to be more close to wm8985. I > can't find any code for triggering those volume update bits after > modified those volume registers. But, the wm8980 datasheet states > that we have to do so to make those volume updates properly. Is there > some black magic in the code? The normal approach for volume update bits is to set them when initialising the CODEC at startup - this is what the wm8990 driver is doing when it writes to the volume registers in wm8990_init(). This means that any further register writes which only change the volume field in the registers will also have the volume update bit set.

1 0

[alsa-devel] Question about snd_dma_buffer bytes field
by Troy Kisky 25 May '09

25 May '09

Does (substream->dma_buffer.bytes) need to equal (snd_pcm_lib_period_bytes(substream) * runtime->periods) ? When this is not true, it seems like the buffer is not being filled correctly. for testing, this works .buffer_bytes_max = 16 * 7 * 512, .period_bytes_min = 32, .period_bytes_max = 7 * 512, /* This is size of ping + pong buffer*/ and this doesn't. .buffer_bytes_max = 16 * 7 * 512 + 512, .period_bytes_min = 32, .period_bytes_max = 7 * 512, /* This is size of ping + pong buffer*/ When playing back a sine wave, I can hear breaks. Thanks Troy

2 2

[alsa-devel] [snd-ctxfi] Test EMU20K2
by Sylvain Loulergue 25 May '09

25 May '09

Hi, Modules snd-ctxfi works fine for me (http://www.alsa-project.org/db/?f=e90356f82f257f499e8028d8a28c98775fd765e7). If you need some specific test just say it. thanks for this devel

1 0

[alsa-devel] Alsamixer isn't working properly with HDA VIA VT82xx with Realtek ALC888 Codec
by Stephan Jänecke 25 May '09

25 May '09

Dear developers, alsamixer doesn't work on my fedora machine. When I type in 'alsamixer -c 0', I get "hda_codec: num-steps=0 for NID=0xf (ctl=Side Playback Volume)" "alsamixer: function snd_mixer_load failed: Invalid argument" Although Pulseaudio and OSS Mixers seem to be present, I don't get any sound. Please have a look at http://www.alsa- project.org/db/?f=15c9f665eb141dee755a533d804456e81442f270 or check the attachment. I hope you can help me solving my problem. Regards, Stephan Jänecke PS: I had the same mixer problem with Mandriva 2009.0 before I installed Fedora 10 to check whether it's an distribution specific bug. Whereas alsamixer didn't work properly as well, I could enjoy working sound. -- Powered by openSUSE 11.1 and KMail 1.10.3

2 5

[alsa-devel] pb with AC'97 codec on atmel at91 boards
by Sedji Gaouaou 25 May '09

25 May '09

Hi all, I am currently working on an AC'97 driver for ATMEL boards(AT91), and I encounter some problems. On the board we have an AD1981b, and looking at the file ac97_patch.c I was wondering in the function patch_ad1881 why is there 3 codecs? I've got the AD1981b datasheet, but the registers description is not really clear to me(vendor id register). My problem is: when I try to read this registers(vendor id) during the probe(in snd_ac97_mixer), it will fail, and from time to time I will even not be able to recognize the codec... So my question is: is that normal that in the function patch_ad1881 the code fails to read these lines: codecs[1] = patch_ad1881_unchained(ac97, 1, (1<<14)); codecs[2] = patch_ad1881_unchained(ac97, 2, (1<<13)); Regards, Sedji

1 0

[alsa-devel] usb audio alsa driver
by wei zhang 25 May '09

25 May '09

hi I was for our devices under linux audio alsa driver, I encountered a lot of trouble now, please help me. My audio device is this: usb interface types, transmission of data through the INT endpoint, each 64 bytes, read out the PCM audio data stream, the sampling rate is 22,050, a single channel, I have the debugging information data crawlers , but I am under no voice in skype, you can tell me the possible reason? Or give me some recommendations, I am very anxious, I would like to thank.I sent my driver, please help me show you, thank you

1 0

Re: [alsa-devel] Help on writing an ALSA ASoC Driver for WM8985
by Leung Chi Tat 25 May '09

25 May '09

Dear Mark, Thank you so much! I right now have a more clear picture. I'm right now studying the driver code for wm8980 codec (from the main trunk of linux-2.6-asoc) as it seems to be more close to wm8985. I can't find any code for triggering those volume update bits after modified those volume registers. But, the wm8980 datasheet states that we have to do so to make those volume updates properly. Is there some black magic in the code? Chitat On Mon, May 25, 2009 at 11:31:48AM +0800, Leung Chi Tat wrote: > 1. describing those important structures, e.g. struct soc_enum, struct snd_kcontrol_new, struct snd_soc_dapm_widget; An enum is used to define an enumerated ALSA control. A kcontrol is a generic ALSA control - there's nothing ASoC specific about it - and a DAPM widget is a thing for which there is power control. > 2. what is/are the relationships among those important structures; > 3. what is the differences between those controls for struct snd_kcontrol_new and struct snd_soc_dapm_widget; It'd be easier to answer this if you had some more specific questions? In general the answer is that things only go into DAPM if they have some relevance to power - that is, if they're a thing for which there is power control or if they control the routing of audio through the chip (and therefore let the core decide which parts of the chip need to be powered on). As has already been suggested the easiest thing is probably to look at other CODEC drivers and compare what their drivers do with the datasheets. > 4. Should those sinks, sources, paths be defined in the arrays of struct snd_dapm_widget; Yes, all the things you have power control for should be there. > 5. How can I select those defined paths through ALSA user-mode library as I can't find any examples in those ALSA tutorials; The controls are all visible as normal ALSA controls - there's nothing ASoC specific in the userspace API. Look with an application such as amixer or alsamixer to see what's there. > Indeed, I'm right now trying to write a WM8985 driver for my s3c6400 based platform based on the kernel source v2.6.21 from Samsung. Note that this is rather old and there were a few issues in the example code with the way that the clocking was set up for the CPU - mostly due to direct access to the system clocking registers which could interfere with other drivers. It might be worth looking at the very latest linux-next tree where there's a mostly complete implementation of audio support.

2 1