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

[alsa-devel] [PATCH] Added model selection for iMac 24"
by Travis Place 19 Jun '08

19 Jun '08

Changelog: Added the SSID of a known iMac 24" to automatically use ALC885_IMAC24 quirk. --- a/pci/hda/patch_realtek.c +++ b/pci/hda/patch_realtek.c @@ -6196,6 +6196,7 @@ static struct snd_pci_quirk alc882_cfg_tbl[] = { SND_PCI_QUIRK(0x1462, 0x28fb, "Targa T8", ALC882_TARGA), /* MSI-1049 T8 */ SND_PCI_QUIRK(0x1462, 0x6668, "MSI", ALC882_6ST_DIG), SND_PCI_QUIRK(0x161f, 0x2054, "Arima W820", ALC882_ARIMA), + SND_PCI_QUIRK(0x106b, 0x00a0, "Apple iMac 24''", ALC885_IMAC24), {} }; Signed-off-by: Travis Place <wishie(a)wishie.net>

2 2

[alsa-devel] What does snd_pcm_delay() actually return?
by Lennart Poettering 19 Jun '08

19 Jun '08

Takashi, Jaroslav, could you please explain what exactly snd_pcm_delay() returns? Some applications (such as WINE) assume it is the time that would pass until we reach an underrun if we would stop writing any further data to the PCM device. Other applications (such as most media players) use it for time synchronisation. i.e. assume that it is the time that passes until a sample I write to a PCM device now would take to be played. Why does this make a difference? For all drivers/ioplug backends where audio is not directly written to the hardware buffer of the audio device the underrun might happen much earlier than the last sample written is heard. This seems to be the case of USB audio for example. If I fill up the hw buffer completely, I will be notified about a buffer underrun much earlier than the buffer size would suggest. Another example is the PulseAudio backend: for each client stream we maintain a private playback buffer. After that buffer there is the hardware buffer. If the client buffer runs empty we'd like to signal an underrun. However, in that situation it still will take some time until the underrun is really hearable, because the audio first has to pass the second buffer in line, the hardware buffer. Or in other words: in some backends (PCI/DMA) after a sample is read from the ALSA playback buffer and the read index is increased it is immediately heard. In others it will still take substantial time until it is heard. The current API doesn't expose any information about how long that additional time can be, and it is not clear if snd_pcm_delay() includes or does not include this extra time in its result. The ALSA documentation claims that snd_pcm_delay() returns the "distance between current application frame position and sound frame position". That would point that WINE's interpretation is correct. (i.e. ignore the extra time) However, the USB audio driver actually seems to return the total time delay as it is useful for synchronization, so follows what media players expect. (i.e. take the extra time into account) I personally believe that the USB audio driver does it right because the most important use for snd_pcm_delay() is to achieve synchronization between audio and video. However, the other value is very important too. Not just for WINE, but also for my own work, PulseAudio. Most of the time the small difference between those two values doesn't really matter, since the difference is very small and for classic PCI/DMI devices zero. However, with USB I am now encountering this problem, because I cannot reliably estimate from the data ALSA supplies me with when the next underrun would happen. Also, the WINE people are pretty vocal that I am not right with my interepretation of the sitaution. Takashi, Jaroslav, could you please eleborate on this, and explain which interpretation is the correct one? Also, regardless which one is the correct one, could we please add a second API function the allows clients to query the other value? I have already raised this issue in differents words two times before [1]. I never got a comment from you on this. So, please please with cream on top, respond! Thank you very much, Lennart [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2008-April/007354.html -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

8 52

[alsa-devel] Linux Plumbers Conference CFP
by Lennart Poettering 19 Jun '08

19 Jun '08

Heya! Anyone doing (audio) infrastructure work on Linux? If so, please make sure to join us at the Linux Plumbers Conference in Portland/Oregon in September. I will be doing an Audio track there and would like to make sure that everyone who does audio infrastructure work will submit a paper, or at least attend, or maybe just know about this conference! It's a conference about the kernel-userspace interfacing, about the lower levels in our software stack. For further details, checkout the conference website: http://www.linuxplumbersconf.org/ Or this blog story of mine: http://0pointer.de/blog/projects/plumbersconf.html Spread the word! Thanks, Lennart (Sorry for this Spam!) -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

2 1

[alsa-devel] [PATCH] Support for MSI K8N v1.0 onboard CA0106 based soundcard
by Travis Place 19 Jun '08

19 Jun '08

NOTE: The Exact model number of the card onboard is unknown to me (SB0438). Not sure how I am to find this information either. For the time being, i have just used the same model as seems to be on the other (updated?) version of the motherboard. Changelog: Add support for the MSI K8N Diamond Motherboard (version 1.0) onboard CA0106 soundcard. --- ca0106_main.c 2008-06-18 04:24:05.000000000 +1000 +++ ca0106_main.c.wishie 2008-06-18 04:39:26.000000000 +1000 @@ -249,6 +249,10 @@ .name = "MSI K8N Diamond MB [SB0438]", .gpio_type = 2, .i2c_adc = 1 } , + { .serial = 0x10091102, + .name = "MSI K8N Diamond MB version 1.0 [SB0438]", + .gpio_type = 2, + .i2c_adc = 1 } , /* Shuttle XPC SD31P which has an onboard Creative Labs * Sound Blaster Live! 24-bit EAX * high-definition 7.1 audio processor". Signed-off-by: Travis Place <wishie(a)wishie.net>

2 1

[alsa-devel] Nvida HDA MCP61 - Realtek ALC622 question
by randall 19 Jun '08

19 Jun '08

Andy: Who works on the snd-hda-intel sound module? I have been unable to get the codec working on my Athlon 64 3200+ processor (64 bit libs) despite gradually working my way up from Alsa 1.0.14 to 1.0.17.git and fighting YaST2 issues with Suse 10.3 Since I do software development, I'd like to add my $0.02 worth of coding to get the Alsa code working for my ECS EliteGroup motherboard as I have seen others posting to the web frustrated by the same problem (indeed openSuse has a web site devoted to soundcard issues, but no one has yet fixed this problem) I did a dump using the alsa-info.sh to pastebin, but probably have to run that again. http://pastebin.ca/1048637 is the latest dump of my board. Randall

2 1

[alsa-devel] snd-hda-intel module now working
by randall 19 Jun '08

19 Jun '08

After rebuilding the kernel about 5 times and double-checking the KMixer controls, I have finally successfully been able to get the onboard sound working. Took 2 days tweaking and rebuilding the kernel. I used the "3stack-6ch-dig" setting for the model and turned on a SND debug variable. - Randall

2 2

[alsa-devel] [PATCH - asihpi 2/2] Disable S24_3LE incompatible with 2^N buffer size.
by linux＠audioscience.com 19 Jun '08

19 Jun '08

From: Eliot Blennerhassett <eblennerhassett(a)audioscience.com> Signed-off-by: Eliot Blennerhassett <eblennerhassett(a)audioscience.com> diff --git a/pci/asihpi/asihpi.c b/pci/asihpi/asihpi.c index ab90b08..c715ad2 100644 --- a/pci/asihpi/asihpi.c +++ b/pci/asihpi/asihpi.c @@ -328,21 +328,28 @@ static void print_hwparams(struct snd_pcm_hw_params *p) static snd_pcm_format_t hpi_to_alsa_formats[] = { -1, /* INVALID */ - SNDRV_PCM_FORMAT_U8, /* { HPI_FORMAT_PCM8_UNSIGNED 1 */ - SNDRV_PCM_FORMAT_S16, /* { HPI_FORMAT_PCM16_SIGNED 2 */ - -1, /* { HPI_FORMAT_MPEG_L1 3 */ - SNDRV_PCM_FORMAT_MPEG, /* { HPI_FORMAT_MPEG_L2 4 */ - SNDRV_PCM_FORMAT_MPEG, /* { HPI_FORMAT_MPEG_L3 5 */ - -1, /* { HPI_FORMAT_DOLBY_AC2 6 */ - -1, /* { HPI_FORMAT_DOLBY_AC3 7 */ - SNDRV_PCM_FORMAT_S16_BE,/* { HPI_FORMAT_PCM16_BIGENDIAN 8 */ - -1, /* { HPI_FORMAT_AA_TAGIT1_HITS 9 */ - -1, /* { HPI_FORMAT_AA_TAGIT1_INSERTS 10 */ - SNDRV_PCM_FORMAT_S32, /* { HPI_FORMAT_PCM32_SIGNED 11 */ - -1, /* { HPI_FORMAT_RAW_BITSTREAM 12 */ - -1, /* { HPI_FORMAT_AA_TAGIT1_HITS_EX1 13 */ - SNDRV_PCM_FORMAT_FLOAT, /* { HPI_FORMAT_PCM32_FLOAT 14 */ - SNDRV_PCM_FORMAT_S24 /* { HPI_FORMAT_PCM24_SIGNED 15 */ + SNDRV_PCM_FORMAT_U8, /* HPI_FORMAT_PCM8_UNSIGNED 1 */ + SNDRV_PCM_FORMAT_S16, /* HPI_FORMAT_PCM16_SIGNED 2 */ + -1, /* HPI_FORMAT_MPEG_L1 3 */ + SNDRV_PCM_FORMAT_MPEG, /* HPI_FORMAT_MPEG_L2 4 */ + SNDRV_PCM_FORMAT_MPEG, /* HPI_FORMAT_MPEG_L3 5 */ + -1, /* HPI_FORMAT_DOLBY_AC2 6 */ + -1, /* HPI_FORMAT_DOLBY_AC3 7 */ + SNDRV_PCM_FORMAT_S16_BE,/* HPI_FORMAT_PCM16_BIGENDIAN 8 */ + -1, /* HPI_FORMAT_AA_TAGIT1_HITS 9 */ + -1, /* HPI_FORMAT_AA_TAGIT1_INSERTS 10 */ + SNDRV_PCM_FORMAT_S32, /* HPI_FORMAT_PCM32_SIGNED 11 */ + -1, /* HPI_FORMAT_RAW_BITSTREAM 12 */ + -1, /* HPI_FORMAT_AA_TAGIT1_HITS_EX1 13 */ + SNDRV_PCM_FORMAT_FLOAT, /* HPI_FORMAT_PCM32_FLOAT 14 */ +#if 1 + /* ALSA can't handle 3 byte sample size together with power-of-2 + * constraint on buffer_bytes, so disable this format + */ + -1 +#else + /* SNDRV_PCM_FORMAT_S24_3LE */ /* { HPI_FORMAT_PCM24_SIGNED 15 */ +#endif }; @@ -978,7 +985,7 @@ static int snd_card_asihpi_playback_open(struct snd_pcm_substream *substream) runtime->hw = snd_card_asihpi_playback; /* Strictly only necessary for HPI6205 adapters */ err = snd_pcm_hw_constraint_pow2(runtime, 0, - SNDRV_PCM_HW_PARAM_BUFFER_SIZE); + SNDRV_PCM_HW_PARAM_BUFFER_BYTES); if (err < 0) return err; @@ -1195,7 +1202,7 @@ static int snd_card_asihpi_capture_open(struct snd_pcm_substream *substream) /* Strictly only necessary for HPI6205 adapters */ err = snd_pcm_hw_constraint_pow2(runtime, 0, - SNDRV_PCM_HW_PARAM_BUFFER_SIZE); + SNDRV_PCM_HW_PARAM_BUFFER_BYTES); if (err < 0) return err; @@ -2025,6 +2032,7 @@ static int snd_asihpi_meter_get(struct snd_kcontrol *kcontrol, short anGain0_01dB[HPI_MAX_CHANNELS], i; u16 err; + //err = HPI_MeterGetRms(phSubSys, hControl, anGain0_01dB); err = HPI_MeterGetPeak(phSubSys, hControl, anGain0_01dB); for (i = 0; i < HPI_MAX_CHANNELS; i++) { -- 1.5.4.3

3 2

[alsa-devel] [PATCH][asihpi] Meter control return peak.
by Eliot Blennerhassett 19 Jun '08

19 Jun '08

Use Peak meter instead of Rms meter because it is supported by all card families. Minor checkpatch cleanups. Signed-off-by: Eliot Blennerhassett <linux(a)audioscience.com> --- diff --git a/pci/asihpi/asihpi.c b/pci/asihpi/asihpi.c index 8cbefab..ab90b08 100644 --- a/pci/asihpi/asihpi.c +++ b/pci/asihpi/asihpi.c @@ -383,15 +383,15 @@ static void snd_card_asihpi_pcm_samplerates(struct snd_card_asihpi *asihpi, rate_max = 100000; } else { /* on cards without SRC, - valid rates are determined by sampleclock */ + valid rates are determined by sampleclock */ err = HPI_MixerGetControl(phSubSys, asihpi->hMixer, HPI_SOURCENODE_CLOCK_SOURCE, 0, 0, 0, HPI_CONTROL_SAMPLECLOCK, &hControl); for (idx = 0; idx < 100; idx++) { if (HPI_ControlQuery(phSubSys, hControl, - HPI_SAMPLECLOCK_SAMPLERATE, idx, 0, - &sampleRate)) + HPI_SAMPLECLOCK_SAMPLERATE, + idx, 0, &sampleRate)) break; rate_min = min(rate_min, sampleRate); @@ -443,7 +443,7 @@ static void snd_card_asihpi_pcm_samplerates(struct snd_card_asihpi *asihpi, } } - /*printk(KERN_INFO "Supported rates %X %d %d\n", + /* printk(KERN_INFO "Supported rates %X %d %d\n", rates, rate_min, rate_max); */ pcmhw->rates = rates; pcmhw->rate_min = rate_min; @@ -885,7 +885,7 @@ static void snd_card_asihpi_playback_format(struct snd_card_asihpi *asihpi, u32 hStream, struct snd_pcm_hardware *pcmhw) { - struct hpi_format hpi_format; + struct hpi_format hpi_format; u16 wFormat; u16 err; u32 hControl; @@ -1126,10 +1126,10 @@ static void snd_card_asihpi_capture_format(struct snd_card_asihpi *asihpi, for (wFormat = HPI_FORMAT_PCM8_UNSIGNED; wFormat <= HPI_FORMAT_PCM24_SIGNED; wFormat++) { - HPI_FormatCreate( - &hpi_format, 2, wFormat, dwSampleRate, 128000, 0); - - err = HPI_InStreamQueryFormat(phSubSys, hStream, + HPI_FormatCreate(&hpi_format, 2, wFormat, dwSampleRate, + 128000, 0); + err = + HPI_InStreamQueryFormat(phSubSys, hStream, &hpi_format); if (!err) pcmhw->formats |= @@ -2025,7 +2025,7 @@ static int snd_asihpi_meter_get(struct snd_kcontrol *kcontrol, short anGain0_01dB[HPI_MAX_CHANNELS], i; u16 err; - err = HPI_MeterGetRms(phSubSys, hControl, anGain0_01dB); + err = HPI_MeterGetPeak(phSubSys, hControl, anGain0_01dB); for (i = 0; i < HPI_MAX_CHANNELS; i++) { #if ASIHPI_LINEAR_METERS @@ -2796,7 +2796,7 @@ int __devinit snd_asihpi_probe(struct pci_dev *pci_dev, asihpi->support_mmap = (!err); asihpi->support_mrx = (((asihpi->wType & 0xFF00) == 0x8900) || - ((asihpi->wType & 0xF000) == 0x6000)); + ((asihpi->wType & 0xF000) == 0x6000)); printk(KERN_INFO "Supports mmap:%d grouping:%d\n", -- -- Eliot Blennerhassett www.audioscience.com

2 1

[alsa-devel] question on hda_codec.c behavior
by randall 18 Jun '08

18 Jun '08

I've not yet been able to get the Nvidia MCP61 (RealTek ALC662) onboard sound working (EliteGroup Computer Systems) on the Athlon 64 3200+ motherboard. A hwinfo is enclosed: 21: PCI 05.0: 0403 Audio device [Created at pci.301] UDI: /org/freedesktop/Hal/devices/pci_10de_3f0 Unique ID: CvwD.9hpqWdunz16 SysFS ID: /devices/pci0000:00/0000:00:05.0 SysFS BusID: 0000:00:05.0 Hardware Class: sound Model: "Elitegroup MCP61 High Definition Audio" Vendor: pci 0x10de "nVidia Corporation" Device: pci 0x03f0 "MCP61 High Definition Audio" SubVendor: pci 0x1019 "Elitegroup Computer Systems" SubDevice: pci 0x2151 Revision: 0xa2 Driver: "HDA Intel" Driver Modules: "snd_hda_intel" Memory Range: 0xfe028000-0xfe02bfff (rw,non-prefetchable) IRQ: 22 (409 events) Module Alias: "pci:v000010DEd000003F0sv00001019sd00002151bc04sc03i00" Driver Info #0: Driver Status: snd_hda_intel is active Driver Activation Cmd: "modprobe snd_hda_intel" Config Status: cfg=no, avail=yes, need=no, active=unknown and the pastebin is http://pastebin.ca/1048637 for all the information on the sound setup. YaST2 does the typical sound card editing, and you can hear the speakers click when the card is (de)activated. But no sound is available, even using the speaker-test command or running alsaconf. I've gradually worked my way up from v1.0.14 to the current v1.0.17rl1 but have no success yet in getting the sound modules to work for the Nvidia MCP61 setup. After posting in the install newsgroup one of the persons trying to help me out suggested that I send a note to the developer's group for the following reason, the /var/log/message file contains the following upon booting up > hda_codec: Unknown model for ALC662, trying auto-probe from BIOS... > ALSA sound/pci/hda/hda_codec.c:2333: autoconfig: line_outs=1 > (0x14/0x0/0x0/0x0/0x0) > ALSA sound/pci/hda/hda_codec.c:2337: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) > ALSA sound/pci/hda/hda_codec.c:2341: hp_outs=1 (0x1b/0x0/0x0/0x0/0x0) > ALSA sound/pci/hda/hda_codec.c:2349: inputs: mic=0x18, fmic=0x19, > line=0x1a, fline=0x0, cd=0x0, aux=0x0 > hda_codec: num_steps = 0 for NID=0xc And the thought was that "Unknown model" should not be occurring. The /etc/modprobe.d/sound file has one of the allowed models for this codec. Any ideas? Does hda_codec.c need a patch? Randall

1 0

Re: [alsa-devel] Listing raw midi devices "The Right Way"?
by Clemens Ladisch 18 Jun '08

18 Jun '08

Jacob Ole Juul Kolding wrote: > I already found a code example that reads raw midi packages form a > specified device but I need to have a complete list of ALL raw midi > capable devices and ports on the system. > > What is the "Right Way" for an app to build such a list? See the source code of amidi. You probably should be using the sequencer instead of the raw MIDI interface, in which case look at the source code of arecordmidi. HTH Clemens

2 2