June 2008 - 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

Re: [alsa-devel] Patchmix-style application for EMU cards
by Camilo Polymeris 30 Aug '10

30 Aug '10

Hello > That is more or less what I had figured out, but it how are playback_1 to > > _16 channels routed to DSP0-15? It seems that it depends on the setting > of > > Front, Surround, LFE, etc. mixer controls. If they are turned up, I > don't > > understand what happens, sound to playback channels appears on various > DSP > > buses, at different levels. > > Really? Well, I didn't much experiment with surround mode. In source code, > I > can see that there are up to playback 8 channels at hw:0,0 with can be > controlled by faders in alsamixer. I tried surround40 and surroun51 on my > emu1616m and it worked as expected. The channles were mapped to first > couple > of DSP ports in a correct order. In fact this should work the same as > audigy > does, except the result is passed to DSP ports instead of physical > outputs. > On my card, playback channels 1 & 2 (hw:0,3) appear on all DSP busses associated with surround. Say you turn up the "Side" fader in alsamixer, channels 1 & 2 will appear at the relevant DSPs (6-7, I think) Whatever, for now I am just keeping all surround controls down (that is, Front, Surround, Center, Side & LFE). > Anyway, I think if there is another layer of routing done in audigy DSP, > it > shouldn't be used in EMU specific application. Or at least not for now. > The > most important thing is to provide all the switches and FPGA routing > scheme > for each EMU model. Or, to be precise, three routing schemes for each EMU > model, because for "double speed" (e.g. 96kHz) and "quadro speed" (e.g. > 192kHz) modes of operation the numebr of both physical and virtual > channels > changes. > I think the switches and enums for the card models are rather trivial, one can handle it with a customized version of qamix (done with a simple XML file), for example. A separate application would not be necessary for only that. > > If I turn the Front/Surround/LFE/etc. faders down, I can mix playback > > channels to DSP using the "Multichannel PCM Send/Routing/Volume" faders, > in > > a more or less intuitive way, besides that routing values do not map > > directly to DSP buses (i.e. 14-15 map to DSP0-1, but 2-3 map to DSP2-3). > Handling of this controls motivated me to write the application in the first place. No sound at all will appear if I don't set the appropiate controls for each playback channel: Multichannel PCM Volume (full), Multichannel PCM Send (an index of 8 controls, the first 4 select the target DSP) & Multichannel PCM Send Volume (again faders 0-3 of 8) By the way, only DSP0-7 work in this way. I have no idea how to make DSP8-31 work. On which card you did tested it? The driver was primary written for the > 1820M/1212M V1, so some things may not work well on other models and need > to > be fixed. I have a 1212m, don't know which version, but I think it's V1-- it does have firewire. I am using driver version 1.0.16. Thanks, Camilo.

3 3

[alsa-devel] snd_pcm_set_params() bug?
by Christian Morales Vega 26 Jan '09

26 Jan '09

This code: #include <alsa/asoundlib.h> int main(){ snd_pcm_t *handle; if(snd_pcm_open(&handle, "default:1", SND_PCM_STREAM_PLAYBACK, 0) < 0) { exit(1); } if(snd_pcm_set_params(handle, SND_PCM_FORMAT_S16_LE, SND_PCM_ACCESS_RW_INTERLEAVED, 2, 24000, 1, 100000) < 0) { exit(2); } } fails with error "ALSA lib pcm.c:7193:(snd_pcm_set_params) Unable to get period size for PLAYBACK: Invalid argument" Disable resampling and you get "ALSA lib pcm.c:7142:(snd_pcm_set_params) Rate doesn't match (requested 24000Hz, get 0Hz)" (normal, I suppose). With other samplerates works fine. I'm using alsa-driver-kmp-default-1.0.16.20080602 and alsa-1.0.16.hg20080510 RPM packages from multimedia:audio openSUSE Build Service repository (from Takashi Iwai) and an AD1988 (hda-intel) codec. A XUbuntu user also has the same problem with an hda-intel codec (that I suppose uses stable 1.0.16). With a SB Live! in the same computer there are no problems. This was discovered with bsnes ( http://byuu.cinnamonpirate.com/bsnes/ - http://board.zsnes.com/phpBB2/viewtopic.php?t=11584 ) that can use openal, libao or alsa directly. The problem just happens when using 24KHz with alsa. So I suppose the problem is in the snd_pcm_set_params() itself, since openal and libao have not the problem but they set parameters "manually", not with snd_pcm_set_params().

3 2

[alsa-devel] snd_pcm_avail_update() needed before snd_pcm_delay() with hda-intel
by Christian Morales Vega 24 Jan '09

24 Jan '09

snd_pcm_avail_update() documentation says: "Using of this function is useless for the standard read/write operations. Use it only for mmap access. See to snd_pcm_delay." snd_pcm_delay() documentation says: "Note this function does not update the actual r/w pointer for applications. The function snd_pcm_avail_update() have to be called before any begin+commit operation." My english is far from perfect, and so the problem can be that I missunderstood the docs but: 1- "Using of this function"? Should not be "Use of this function"? 2- Is snd_pcm_avail_update() really useless when not using mmap? I have a SB Live! where snd_pcm_delay() always returns the correct value, without any need for snd_pcm_avail_update(). But the same code in the same machine with an hda-intel AD1988 needs a call to snd_pcm_avail_update() before snd_pcm_delay() to give the correct result. Without it snd_pcm_delay() always returns the value that *was* correct in the last snd_pcm_writei() call. So should the "application frame position" be always updated, or only in read/write operations? In the first case AD1988 fails, in the second case perhaps SB Live! is making too mucho work ;-)

4 9

[alsa-devel] snd_pcsp locking mess
by Stas Sergeev 21 Oct '08

21 Oct '08

bugme-daemon(a)bugzilla.kernel.org wrote: > ------- Comment #17 from tiwai(a)suse.de 2008-05-18 10:22 ------- > Anyway, what I meant is that the part touching I/O ports could be a faster path > than softirq. And the hrtimer code can use a bit simpler locks. The hrtimer > callback needs just one thing about DMA buffer - the buffer is allocated and > the address doesn't change during the callback. So, we'd need the lock for the > hr callback and for the PCM prepare, hwparams and free callbacks, i.e. to > assure that the hrtimer callback is finished when these PCM callbacks may > change the DMA buffer. Thus this lock doesn't have to be PCM substream lock. I wonder if it would be better to introduce such a lock in an alsa core rather than in a driver. The same way as snd_pcm_stream_lock(). > The current lock mess may come from the PCM trigger (STOP) called from > snd_pcm_period_elapsed(). So, putting snd_pcm_period_elapsed() out of hrtimer > lock is anyway necessary. A tasklet for snd_pcm_period_elapsed() is needed for > this reason, too. Wouldn't it be better to just make snd_pcm_period_elapsed() to not take the stream lock? There is a requirement right now to drop the stream lock before calling this. I still beleive this is the root of all the headache. If you need to drop it, then you either accept the race or need a second lock, and the troubles ensue.

2 22

[alsa-devel] X-Fi support in ALSA.
by James Courtier-Dutton 18 Sep '08

18 Sep '08

Hi, I have now had a chance to read some of the specs of the X-Fi cards. aka. emu20k1. It turns out that some of the X-Fi cards have a compatibility mode. By default, they boot up in compatibility mode. The interesting point is that this "compatibility mode" is in fact the intel-HD standard so could use the intel-hda driver. For one X-Fi card with IDs: Device 1102:0009 Subsystem: 1102:0010 works a bit with the ALSA hda-intel driver. So far, the off the shelf hda-intel driver, with simple PCIs adjustment, works for the above card, but only sound capture works so far, so probably some quirk would be needed. This compatibility mode works with the Windows Vista UAA drivers. Not all X-Fi cards support with compatibility mode. For example, any card with (after a cold boot into Linux) Device 1102:0005 Subsystem: xxxx:xxxx will be X-Fi only. With regard to actual full X-Fi support, I am still in the progress of creating a GPL emu20k1.h file, that is the first step towards an snd-emu20k1 native ALSA driver. James

3 3

Re: [alsa-devel] [Fwd: [Alsa-user] Intel Poulsbo(SCH) chipset does not recognize Adi 1986 codec under linux]]
by Kan-I Jyo 01 Aug '08

01 Aug '08

Dear list, My original mail on this topic was posted to the alsa-user list, while I was informed that this alsa-devel list would be the right place to post. The problem I had encountered is that the Adi 1986 codec chip on my device with Poulsbo(SCH) chipset could not be recognized by the snd_hda_intel driver module. Tobin has kindly given me an advice on trying an ALSA driver that is later than 1.0.16.final. For a cross-test pupose, I have tried both the following 1.0.16 and the latest 1.0.17-rc2. [1.0.16] ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.16.tar.bz2 [1.0.17-rc2] ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.17rc2.tar.bz2 By following the guide described in the INSTALL text file in both the above two packages, I have done make and make install without a problem. Unfortunately, both these two version of ALSA driver does not recognized the Adi 1986 codec and in the dmesg output claiming that "no codecs found!". <dmesg> -- snip -- ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 16 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:00:1b.0 to 64 ALSA /root/alsa-driver-1.0.16/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:1887: hda-intel: no codecs found! ACPI: PCI interrupt for device 0000:00:1b.0 disabled ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 16 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:00:1b.0 to 64 ALSA /root/alsa-driver-1.0.17rc2/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:2142: hda-intel: no codecs found! ACPI: PCI interrupt for device 0000:00:1b.0 disabled -- snip -- I have also tried applying some module parameters like probe_mask and position_fix but with no luck. Actually, we have two machines with Poulsbo(SCH) chipset inside. The ALSA driver works fine in one(with a chipset's revision of "04") while it does not work on the other (with a chipset's revision of "06"). Here I attach the "lspci -nnvvvxxxx" result from both two machines. Any comment would be greatly appericiated. If anyone needs more information, please let me know. ---------- Forwarded message ---------- 2008/6/24 stan <ghjeold_i_mwee(a)cox.net>: > This is a response from the alsa-devel list. I forwarded your message there > as that was the more appropriate list. > > > Not sure what version of alsa driver you are using, but the driver for that > chipset was added prior to 1.0.16 final. Anything after that should work. > > Tobin > > On Mon, 2008-06-23 at 06:20 -0700, stan wrote: > > Sent to wrong list. > > email message attachment ([Alsa-user] Intel Poulsbo(SCH) chipset does not > recognize Adi 1986 codec under linux.eml) > > -------- Forwarded Message -------- > From: Kan-I Jyo <cecilhsujp(a)gmail.com> > To: alsa-user(a)lists.sourceforge.net > Subject: [Alsa-user] Intel Poulsbo(SCH) chipset does not recognize Adi 1986 > codec under linux > Date: Mon, 23 Jun 2008 20:53:42 +0900 > > Dear list, > > I have recently got a device with Intel's Poulsbo chipset and Adi 1986 > codec attatched. > > The Adi 1986 codec along with the Poulsbo chipset could been > recognized by installing the SoundMAX driver under Windows XP. > > While switching to Linux, the snd_intel_hda is loaded but the Adi 1986 > codec could not been seen and there is no "codec#0" entry under > /proc/asound/card0. > > >From what I can see from dmesg, the hda_intel module had complained > about "no codecs found!". > > <dmesg.txt> > -- snip -- > [ 93.463277] PCI: Setting latency timer of device 0000:00:1b.0 to 64 > [ 93.463286] Do fixup for Poulsbo <6>D0 or newer stepping > [ 93.463439] HDA snoop disabled, try to enable ... OK > [ 93.491624] hda-intel: no codecs found! > -- snip -- > > I have attached both output of dmesg command the "lspci -nnvvvxxx" > result along with this mail. Any comment would be greatly appreciated. > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ Alsa-user mailing list > Alsa-user(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/alsa-user > > _______________________________________________ Alsa-devel mailing list > Alsa-devel(a)alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > -- Tobin Davis > > 22. The only copy of Norton Utilities was on THAT disk??? > > --Top 100 things you don't want the sysadmin to say > > -- Sincerely, Jyo

3 11

[alsa-devel] Requiring the same sample rate for playback and record?
by Timur Tabi 25 Jul '08

25 Jul '08

In my driver, how do I tell ALSA that the sample rate for playback must be the same as for capture? I know I can have my driver remember the sample rate for the first stream open, and then if the second stream doesn't specify the same sample rate, it can reject it, but this is inelegant. I'm hoping there's a more straightforward way. -- Timur Tabi Linux kernel developer at Freescale

3 11

[alsa-devel] Setting format to SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters
by Mitul Sen (misen) 24 Jul '08

24 Jul '08

I am a newbie to ALSA and any help will be much appreciated. I have an application which sets up the signaling between an IP phone and my desktop and then sets up the audio path between the two. On my desktop application, I am able to receive RTP packets from IP phone. I use an RTP stack to parse the data and after going through the RTP stack, I try to play back the audio using ALSA. When I use the ALSA code to play back (in real time) using sound card of my device, there is only noise, I cannot hear the audio that I speak into the IP phone. However, if I take the raw data coming from the RTP stack and write it to a file, I can play back the file successfully. Since my data from IP phone is G.711 encoded, I have set the sampling rate within ALSA to 8000. Also I am using one source (mono) and non-interleaved data option for preparing ALSA for playback. When I set the format to SND_PCM_FORMAT_MU_LAW, at runtime it lets me set that format ie. snd_pcm_hw_params_set_format (for SND_PCM_FORMAT_MU_LAW) is successful. However I get a runtime error while applying the hardware parameters using snd_pcm_hw_params(..) if the format set earlier is SND_PCM_FORMAT_MU_LAW. Using any other format like SND_PCM_FORMAT_U8 or SND_PCM_FORMAT_S8, lets me apply the hardware parameters but it gives the problem of the noise (no "audible" voice) that I described earlier. This is what my ALSA code looks like ***** beginning of code snippet ***************** int err; snd_pcm_hw_params_t *hw_params; // Try to open the default device err = snd_pcm_open( &_soundDevice, "plughw:0,0", SND_PCM_STREAM_PLAYBACK, 0 ); // Check for error on open. if( err < 0 ) { printf("Init: cannot open audio device\n"); return -1; } // Allocate the hardware parameter structure. if ((err = snd_pcm_hw_params_malloc (&hw_params)) < 0) { printf("Init: cannot allocate hardware parameter structure\n"); return -1; } if ((err = snd_pcm_hw_params_any (_soundDevice, hw_params)) < 0) { printf("Init: cannot initialize hardware parameter structure\n"); return -1; } // Set access to RW interleaved. if ((err = snd_pcm_hw_params_set_access (_soundDevice, hw_params, SND_PCM_ACCESS_RW_NONINTERLEAVED)) < 0) { printf("Init: cannot set access type\n"); return -1; } if ((err = snd_pcm_hw_params_set_format (_soundDevice, hw_params, SND_PCM_FORMAT_MU_LAW)) < 0) { return -1; } // Set channels to mono (1) if ((err = snd_pcm_hw_params_set_channels (_soundDevice, hw_params, 1)) < 0) { return -1; } // Set sample rate. unsigned int actualRate = 8000; if ((err = snd_pcm_hw_params_set_rate_near (_soundDevice, hw_params, &actualRate, 0)) < 0) { return -1; } // Apply the hardware parameters that we've set. if ((err = snd_pcm_hw_params (_soundDevice, hw_params)) < 0) { printf("Audio device parameters have not been set successfully.(%s)(%s)\n", strerror (err), snd_strerror (err)); return -1; } // Free the hardware parameters now that we're done with them. snd_pcm_hw_params_free (hw_params); /* Prepare interface for use. if ((err = snd_pcm_prepare (_soundDevice)) < 0) { printf("Audio device not prepared for use\n"); return -1; } // If the frames are received... /* find out how much space is available for playback data if ((frames_to_deliver = snd_pcm_avail_update (_soundDevice)) < 0) { printf("Error returned by snd_pcm_avail_update\n"); } frames_to_deliver = frames_to_deliver > 4096 ? 4096 : frames_to_deliver; printf("frames to deliver is %d\n",(int)frames_to_deliver); */ frames_to_deliver = 172; bufs[1] = (void*)buffer; if ((err = snd_pcm_writen( _soundDevice, bufs, frames_to_deliver)) < 0) { printf ("write failed (%s)\n", snd_strerror (err)); } ****************** end of code snippet ********************************** The error I get is as follows:- Audio device parameters have not been set successfully.(Unknown error 4294967274)(Invalid argument) Any pointers on what I could be doing wrong? Thanks and regards, Mitul

3 14

[alsa-devel] Still have choppy audio using 1.0.17
by Gustavo da Silva Serra 16 Jul '08

16 Jul '08

I have been trying for many weeks to solve this problem, but with no success. After updating to Alsa 1.0.17, which include changes to aloop, I still have choppy audio. I will try to summarize what happens: - I need to use aloop, if I change to a sound card all the problems are gone; - After some time of continuous play, applications start to reproduce choppy audio. Choppy audio doesn't happens all the time; - If I repeatedly start and stop my sound capture application choppy audio occur sooner; - Start/stop my application restores the sound quality (after some tryies); - This happens with ALSA applications (xine, vlc) and OSS emulated; - I have tryied many period_size and buffer_size in asound.conf, now I am using 960 for period and 3840 for buffer. As I decrease period size, the audio quality improves, but choppy audio still happens; - I test for overrun but no errors occur. - I am using block mode, interleaved, 44100, 16 bit, 2 channels - I am using dmix, dsnoop, removing them does not correct the audio These are some of the information I have, I don't know if is is enough. If necessary I can provide any other information. What do you suggest that I do? Are there any known issues or configuration requirements? Thanks in advance.

3 17

[alsa-devel] Audigy bay protocol
by Tony "Chainsaw" Vroon 01 Jul '08

01 Jul '08

Good afternoon, Having spent some time looking at the MIDI that the internal/external Audigy bays emit, I noticed that they report more then is currently used by the LIRC driver. There is one thing missing in here, which is how to control the bay power LED (which is supposed to blink when the card is muted) and the CMSS LED. I am not sure whether this is controlled through MIDI SysEx sequences or through other means. Due to an annoying hardware failure in my Audigy 4 Pro I can not continue this endeavour, but I want to share what I have. Based on this, perhaps one can extend the EMU10K1/2 driver a bit with headphone muting and volume control through the bay. With thanks to the libdouze author, Arnaud de Bossoreille de Ribou. Midi System Exclusive ( extended manufacturer id == 0x2021 ) Payload for 61 bay message: 61 00 01 00 XX YY XX 00 = button push event 01 = volume knob event 02 = jack sense event For XX=00 button push: Bit 1: CMSS Bit 2: Mute For XX=01 volume knob: Bit 1: Always set Bit 7: Set for downward adjustment, unset for upward adjustment For XX=02 jack sense: YY contains jacks Bit 1: headphone Bit 2: digital out (back of bay) Response to initialization: Midi System Exclusive ( extended manufacturer id == 0x2021, payload == | 60 00 02 03 | ) <-- Unknown, bay version? Midi System Exclusive ( extended manufacturer id == 0x2021, payload == | 61 00 01 00 02 01 | ) <-- Jack sense update I hope it is of use to someone. Regards, Tony V.

2 2

Re: [alsa-devel] looping S/PDIF data
by Rene Herman 01 Jul '08

01 Jul '08

On 17-06-08 21:55, Pierre Ossman wrote: > Ping > > On Sat, 31 May 2008 11:26:06 +0200 > Pierre Ossman <drzeus-list(a)drzeus.cx> wrote: > >> I have a minor annoyance with the snd_trident driver that I was hoping >> you might have a fix for: >> >> Pausing the output does not seem to take on the S/PDIF output. Analog >> outputs properly stop in their tracks, but the S/PDIF port keeps >> looping the current data buffer, which gives a rather unpleasant end >> result. :) Try the alsa-devel list... Rene.

4 15

[alsa-devel] [PATCH] [alsa-utils] Fix build with library options disabled
by Sean McNamara 01 Jul '08

01 Jul '08

Hello, It's been a perennial problem with alsa-utils that there is no configure option to disable the seq and amidi apps. These apps depend on how you configured alsa-lib: If you pass --disable-seq --disable-instr to the alsa-lib configure, there does not currently exist a configure-time option to allow alsa-utils to build against this particular alsa-lib. Of course, you could hack makefiles and stuff so it doesn't build seq and amidi, but I thought it would be nice to commit changes to the configure.in and Makefile.am to upstream, so that we can disable seq and amidi the "right" way. The attached patches are diffed against the latest revision of alsa-utils. With this change, you can: 1. Disable building amidi by passing --disable-midi to the configure in alsa-utils. 2. Disable building seq by passing --disable-seq to the configure in alsa-utils. With this change, we can get a "good" build of alsa-utils (albeit, missing two of the utilities, which is intended) in the following circumstances: 1. seq and instr are DISABLED in alsa-lib; seq and midi are DISABLED in alsa-utils 2. seq and instr are ENABLED in alsa-lib; seq and midi are ENABLED in alsa-utils (the default). 3. seq and instr are ENABLED in alsa-lib; seq and midi are DISABLED in alsa-utils. Of course, it does not build cleanly if seq and instr are DISABLED in alsa-lib, but seq and midi are ENABLED in alsa-utils. Patches are attached -- please let me know if there any issues, and if not, could one of the committers please commit them. Thanks, Sean

2 1

[alsa-devel] [PATCH] Add some system information to alsa-info.sh output
by Travis Place 01 Jul '08

01 Jul '08

First some information about this.. I was planning on using dmidecode to fetch this information, but that required 1) the script be run as root, and 2) requires the user to have dmidecode installed (most people wouldnt). So we fetch from /sys/ (if available). Patch attached. Changelog: Fetch the board_vendor, product_version and product_name from DMI in /sys/ (if available). Increased alsa-info.sh version to 0.4.49. Signed-off-by: Travis Place <wishie(a)wishie.net>

3 6

[alsa-devel] [PATCH/RFC 1/2] Add jack reporting API for ALSA
by Mark Brown 01 Jul '08

01 Jul '08

Currently very few systems provide information about jack status to user space, even though many have hardware facilities to do detection. Those systems that do use an input device with the existing SW_HEADPHONE_INSERT switch type to do so, often independently of ALSA. This patch introduces a standard method for representing jacks to user space into ALSA. It allows drivers to register jacks for a sound card with the input subsystem, binding the input device to the card to help user space associate the input devices with their sound cards. The created input devices are named in the form "card longname jack" where jack is provided by the driver when allocating a jack. The existing user space API with SW_HEADPHONE_INSERT is preserved. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- include/sound/core.h | 1 + include/sound/jack.h | 51 +++++++++++++++++++ sound/core/Kconfig | 5 ++ sound/core/Makefile | 2 + sound/core/jack.c | 136 ++++++++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 195 insertions(+), 0 deletions(-) create mode 100644 include/sound/jack.h create mode 100644 sound/core/jack.c diff --git a/include/sound/core.h b/include/sound/core.h index ee2d7e1..8c87713 100644 --- a/include/sound/core.h +++ b/include/sound/core.h @@ -53,6 +53,7 @@ typedef int __bitwise snd_device_type_t; #define SNDRV_DEV_INFO ((__force snd_device_type_t) 0x1006) #define SNDRV_DEV_BUS ((__force snd_device_type_t) 0x1007) #define SNDRV_DEV_CODEC ((__force snd_device_type_t) 0x1008) +#define SNDRV_DEV_JACK ((__force snd_device_type_t) 0x1009) #define SNDRV_DEV_LOWLEVEL ((__force snd_device_type_t) 0x2000) typedef int __bitwise snd_device_state_t; diff --git a/include/sound/jack.h b/include/sound/jack.h new file mode 100644 index 0000000..e5ac26c --- /dev/null +++ b/include/sound/jack.h @@ -0,0 +1,51 @@ +#ifndef __SOUND_JACK_H +#define __SOUND_JACK_H + +/* + * Jack abstraction layer + * + * Copyright 2008 Wolfson Microelectronics plc + * + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + */ + +#include <sound/core.h> + +struct input_dev; + +/** + * Jack types which can be reported. These values are used as a + * bitmask. + */ +enum snd_jack_types { + SND_JACK_HEADPHONE = 0x0001, +}; + +struct snd_jack { + struct input_dev *input_dev; + int registered; + int type; + const char *id; + char name[100]; +}; + +int snd_jack_new(struct snd_card *card, const char *id, int type, + struct snd_jack **jack); + +void snd_jack_report(struct snd_jack *jack, int status); + +#endif diff --git a/sound/core/Kconfig b/sound/core/Kconfig index 829ca38..4e8e52d 100644 --- a/sound/core/Kconfig +++ b/sound/core/Kconfig @@ -16,6 +16,11 @@ config SND_RAWMIDI tristate depends on SND +config SND_JACK + tristate + depends on SND + depends on INPUT + config SND_SEQUENCER tristate "Sequencer support" depends on SND diff --git a/sound/core/Makefile b/sound/core/Makefile index 5a01c76..e1cb6d6 100644 --- a/sound/core/Makefile +++ b/sound/core/Makefile @@ -20,9 +20,11 @@ snd-rawmidi-objs := rawmidi.o snd-timer-objs := timer.o snd-rtctimer-objs := rtctimer.o snd-hwdep-objs := hwdep.o +snd-jack-objs := jack.o obj-$(CONFIG_SND) += snd.o obj-$(CONFIG_SND_HWDEP) += snd-hwdep.o +obj-$(CONFIG_SND_JACK) += snd-jack.o obj-$(CONFIG_SND_TIMER) += snd-timer.o obj-$(CONFIG_SND_RTCTIMER) += snd-rtctimer.o obj-$(CONFIG_SND_PCM) += snd-pcm.o snd-page-alloc.o diff --git a/sound/core/jack.c b/sound/core/jack.c new file mode 100644 index 0000000..1a52997 --- /dev/null +++ b/sound/core/jack.c @@ -0,0 +1,136 @@ +/* + * Jack abstraction layer + * + * Copyright 2008 Wolfson Microelectronics + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + */ + +#include <linux/input.h> +#include <sound/jack.h> +#include <sound/core.h> + +static int snd_jack_dev_free(struct snd_device *device) +{ + struct snd_jack *jack = device->device_data; + + /* If the input device is registered with the input subsystem + * then we need to use a different deallocator. */ + if (jack->registered) + input_unregister_device(jack->input_dev); + else + input_free_device(jack->input_dev); + + kfree(jack); + + return 0; +} + +static int snd_jack_dev_register(struct snd_device *device) +{ + struct snd_jack *jack = device->device_data; + struct snd_card *card = device->card; + int err; + + snprintf(jack->name, sizeof(jack->name), "%s %s", + card->longname, jack->id); + jack->input_dev->name = jack->name; + + err = input_register_device(jack->input_dev); + if (err == 0) + jack->registered = 1; + + return err; +} + +/** + * snd_jack_new - Create a new jack + * @card: the card instance + * @id: an identifying string for this jack + * @type: a bitmask of enum snd_jack_type values that can be detected by + * this jack + * @jjack: Used to provide the allocated jack object to the caller. + * + * Creates a new jack object. + * + * Returns zero if successful, or a negative error code on failure. + * On success jjack will be initialised. + */ +int snd_jack_new(struct snd_card *card, const char *id, int type, + struct snd_jack **jjack) +{ + struct snd_jack *jack; + int err; + static struct snd_device_ops ops = { + .dev_free = snd_jack_dev_free, + .dev_register = snd_jack_dev_register, + }; + + jack = kzalloc(sizeof(struct snd_jack), GFP_KERNEL); + if (jack == NULL) + return -ENOMEM; + + jack->id = id; + + jack->input_dev = input_allocate_device(); + if (jack->input_dev == NULL) { + err = -ENOMEM; + goto fail_input; + } + + jack->input_dev->phys = "ALSA"; + jack->input_dev->dev.parent = card->dev; + + jack->type = type; + + if (type & SND_JACK_HEADPHONE) + input_set_capability(jack->input_dev, EV_SW, + SW_HEADPHONE_INSERT); + + err = snd_device_new(card, SNDRV_DEV_JACK, jack, &ops); + if (err < 0) + goto fail_input; + + *jjack = jack; + + return 0; + +fail_input: + input_free_device(jack->input_dev); + kfree(jack); + return err; +} +EXPORT_SYMBOL(snd_jack_new); + +/** + * snd_jack_report - Report the current status of a jack + * + * @jack: The jack to report status for + * @status: The current status of the jack + */ +void snd_jack_report(struct snd_jack *jack, int status) +{ + if (jack->type & SND_JACK_HEADPHONE) + input_report_switch(jack->input_dev, SW_HEADPHONE_INSERT, + status & SND_JACK_HEADPHONE); + + input_sync(jack->input_dev); +} +EXPORT_SYMBOL(snd_jack_report); + +MODULE_AUTHOR("Mark Brown <broonie(a)opensource.wolfsonmicro.com>"); +MODULE_DESCRIPTION("Jack detection support for ALSA"); +MODULE_LICENSE("GPL"); -- 1.5.5.1

3 12

[alsa-devel] ALSA with Ubuntu 8.04
by Eliot Blennerhassett 28 Jun '08

28 Jun '08

This just an FYI In Ubuntu 8.04, ubuntu has packaged alsa-drivers including some out of tree drivers in a separate package: linux-ubuntu-modules-$kernelver This gets installed in /lib/modules/$kernelver/ubuntu/sound The only things installed in /lib/modules/$kernelver/sound are soundcore.ko and ac97_bus.ko However, when you do a default "make install" from alsa-driver source, the modules get installed in /lib/modules/$kernelver/kernel/sound So, now there are 2 copies of the drivers in different places. I have taken to removing (moving away to say /root) /lib/modules/$kernelver/ubuntu/sound to avoid any confusion and some odd module versioning problems that I was having. regards Eliot.

4 3

[alsa-devel] softvol chokes on snd_pcm_rewind
by Lennart Poettering 28 Jun '08

28 Jun '08

Hey! On 1.0.16 softvol sometimes chokes on snd_pcm_rewind(): the command suceeds but the sound is heavily distorted from then on. Takashi, Jaroslav, is this known? Any short-term workaround? Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

2 1

[alsa-devel] emu20k1 in 1.0.17?
by daedra 28 Jun '08

28 Jun '08

I was just wondering if there is a chance of the emu20k1 driver making it's way into 1.0.17?

3 3

[alsa-devel] seg fault with 1.0.17rc2
by Jerry Geis 27 Jun '08

27 Jun '08

#0 0xb7e892ff in memcpy () from /lib/tls/libc.so.6 #1 0xb74e40a9 in snd_pcm_area_copy (dst_area=0xb7125b70, dst_offset=0, src_area=0x81dc1c0, src_offset=170, samples=0, format=SND_PCM_FORMAT_S16_LE) at pcm.c:2589 #2 0xb74e438d in snd_pcm_areas_copy (dst_areas=0xb7125b7c, dst_offset=0, src_areas=0x81dc1cc, src_offset=170, channels=1, frames=122, format=SND_PCM_FORMAT_S16_LE) at pcm.c:2736 #3 0xb74ee0a1 in snd_pcm_mmap_read_areas (pcm=0x81de3b8, areas=0xb7125b70, offset=0, size=122) at pcm_mmap.c:151 #4 0xb74e350d in snd1_pcm_read_areas (pcm=0x81de3b8, areas=0xb7125b70, offset=0, size=122, func=0xb74edfd0 <snd_pcm_mmap_read_areas>) at pcm.c:6501 #5 0xb74ed2df in snd_pcm_mmap_readi (pcm=0x81de3b8, buffer=0xb6352a04, size=122) at pcm_mmap.c:236 #6 0xb74dbb14 in snd_pcm_readi (pcm=0x81de110, buffer=0xb6352a04, size=61) at pcm_local.h:526 #7 0xb756279b in alsa_read (chan=0x821c928) at chan_alsa.c:683 #8 0x080855b1 in __ast_read (chan=0x821c928, dropaudio=0) at channel.c:2100 I am using a usb-audio device. Bus 003 Device 001: ID 0000:0000 Bus 003 Device 002: ID 0d8c:000c C-Media Electronics, Inc. Audio Adapter Bus 002 Device 002: ID 13fe:1f00 Bus 002 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 001 Device 001: ID 0000:0000 I am using this as my asound.conf file pcm.usb-audio { type hw card 0 } ctl.usb-audio { type hw card 0 } I am using debian etch 2.6.18-6-486 #1 Fri Jun 6 21:47:01 UTC 2008 i486 GNU/Linux It works for a couple times then I get the seg fault. I am using the Console output from asterisk. help? Thanks, Jerry

2 9

[alsa-devel] ALSA 1.0.17rc3 release (driver only)
by Jaroslav Kysela 27 Jun '08

27 Jun '08

Hello all, ALSA driver package v1.0.17rc3 is released. I hope that all remaining bugs for compilation with 2.4 kernels are fixed. Changes are available here: http://www.alsa-project.org/main/index.php/Changes_v1.0.17rc2_v1.0.17rc3 Jaroslav ----- Jaroslav Kysela <perex(a)perex.cz> Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.

2 1

Re: [alsa-devel] [alsa-cvslog] alsa-kmirror: ALSA kernel mirror repository branch, master now at 9d46f4a919532c3f29a4ca1df3a4ce4686b11f37
by Thierry Vignaud 27 Jun '08

27 Jun '08

noreply-git(a)alsa-project.org writes: > Hello, > > This is an automated email from the git hooks/update script, it was > generated because a ref change was pushed to the repository. > > Updating branch, master, > via 9d46f4a919532c3f29a4ca1df3a4ce4686b11f37 (commit) > from fc5102d6c6520f48d39faf572881bc520c41aeb7 (commit) > > - Log ----------------------------------------------------------------- > commit 9d46f4a919532c3f29a4ca1df3a4ce4686b11f37 > Author: Jaroslav Kysela <perex(a)perex.cz> > AuthorDate: Tue May 20 13:25:35 2008 +0200 > Commit: Jaroslav Kysela <perex(a)perex.cz> > CommitDate: Tue May 20 13:25:35 2008 +0200 > > removed .hgtags can we make the log appears in subject instead of useless sha1 ID?

5 16

[alsa-devel] Building trouble - redefinition of struct timeval
by Caloro Maurizio 27 Jun '08

27 Jun '08

Please i need help for following error message "redefinition of struct timeval - /include/global.h" the configure script run without any Error, if i compile "alsa-lib-1.0.17rc2" on I386 Netbsd 4.0 i receive folowing error break. "./configure --prefix=/usr --sysconfdir=/etc --build=i386-unknown-netbsdelf4.0 --host=i386-unknown-netbsdelf4.0 --target=i386-unknown-netbsdelf4.0 --with-pythonlibs=lpython2.5 --with-pythonincludes=-I/usr/include/python2.5 --enable-shared=no --enable-static=yes" & gmake gmake ... > Making all in controll gmake[1]: Entering directory `/usr/source/alsa-lib-1.0.17rc2/src/control' if /bin/ksh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -g -O2 -MT cards.lo -MD -MP -MF ".deps/cards.Tpo" -c -o cards.lo cards.c; \ then mv -f ".deps/cards.Tpo" ".deps/cards.Plo"; else rm -f ".deps/cards.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -g -O2 -MT cards.lo -MD -MP -MF .deps/cards.Tpo -c cards.c -o cards.o In file included from ../../include/local.h:109, from control_local.h:22, from cards.c:35: ../../include/global.h:138: error: redefinition of 'struct timeval' ../../include/global.h:143: error: redefinition of 'struct timespec' gmake[1]: *** [cards.lo] Error 1 gmake[1]: Leaving directory `/usr/source/alsa-lib-1.0.17rc2/src/control' gmake: *** [all-recursive] Error 1 i have see that this its a possible handle with Posix_C_Source but i dont found the correct answer for me trouble.... Please for any Help i'am happy. thanks MC -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

2 5

[alsa-devel] [alsa-kernel][PATCH] ASoC: TLV320AIC3X: Add mixer control for ADC highpass filter
by Jarkko Nikula 27 Jun '08

27 Jun '08

Signed-off-by: Jarkko Nikula <jarkko.nikula(a)nokia.com> --- sound/soc/codecs/tlv320aic3x.c | 6 ++++++ sound/soc/codecs/tlv320aic3x.h | 2 ++ 2 files changed, 8 insertions(+), 0 deletions(-) diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c index 4f0bf26..d138306 100644 --- a/sound/soc/codecs/tlv320aic3x.c +++ b/sound/soc/codecs/tlv320aic3x.c @@ -223,6 +223,8 @@ static const char *aic3x_right_hpcom_mux[] = { "differential of HPROUT", "constant VCM", "single-ended", "differential of HPLCOM", "external feedback" }; static const char *aic3x_linein_mode_mux[] = { "single-ended", "differential" }; +static const char *aic3x_adc_hpf[] = + { "Disabled", "0.0045xFs", "0.0125xFs", "0.025xFs" }; #define LDAC_ENUM 0 #define RDAC_ENUM 1 @@ -232,6 +234,7 @@ static const char *aic3x_linein_mode_mux[] = { "single-ended", "differential" }; #define LINE1R_ENUM 5 #define LINE2L_ENUM 6 #define LINE2R_ENUM 7 +#define ADC_HPF_ENUM 8 static const struct soc_enum aic3x_enum[] = { SOC_ENUM_SINGLE(DAC_LINE_MUX, 6, 3, aic3x_left_dac_mux), @@ -242,6 +245,7 @@ static const struct soc_enum aic3x_enum[] = { SOC_ENUM_SINGLE(LINE1R_2_RADC_CTRL, 7, 2, aic3x_linein_mode_mux), SOC_ENUM_SINGLE(LINE2L_2_LADC_CTRL, 7, 2, aic3x_linein_mode_mux), SOC_ENUM_SINGLE(LINE2R_2_RADC_CTRL, 7, 2, aic3x_linein_mode_mux), + SOC_ENUM_DOUBLE(AIC3X_CODEC_DFILT_CTRL, 6, 4, 4, aic3x_adc_hpf), }; static const struct snd_kcontrol_new aic3x_snd_controls[] = { @@ -292,6 +296,8 @@ static const struct snd_kcontrol_new aic3x_snd_controls[] = { /* Input */ SOC_DOUBLE_R("PGA Capture Volume", LADC_VOL, RADC_VOL, 0, 0x7f, 0), SOC_DOUBLE_R("PGA Capture Switch", LADC_VOL, RADC_VOL, 7, 0x01, 1), + + SOC_ENUM("ADC HPF Cut-off", aic3x_enum[ADC_HPF_ENUM]), }; /* add non dapm controls */ diff --git a/sound/soc/codecs/tlv320aic3x.h b/sound/soc/codecs/tlv320aic3x.h index c1dd1ac..e600946 100644 --- a/sound/soc/codecs/tlv320aic3x.h +++ b/sound/soc/codecs/tlv320aic3x.h @@ -37,6 +37,8 @@ #define AIC3X_ASD_INTF_CTRLB 9 /* Audio overflow status and PLL R value programming register */ #define AIC3X_OVRF_STATUS_AND_PLLR_REG 11 +/* Audio codec digital filter control register */ +#define AIC3X_CODEC_DFILT_CTRL 12 /* ADC PGA Gain control registers */ #define LADC_VOL 15 -- 1.5.5.4

2 1

[alsa-devel] [PATCH] Add another VIA audio chip to ac97 quirks list
by walt 27 Jun '08

27 Jun '08

Author: Walter Sheets <w41ter(a)gmail.com> Date: Thu Jun 26 10:39:19 PDT 2008 x86: Add VIA audio device #1841 to ac97_quirk list Signed-off-by: Walter Sheets <w41ter(a)gmail.com> --- Takashi, feel free to modify this in any way you need to. Thanks. diff --git a/sound/pci/via82xx.c b/sound/pci/via82xx.c index b585cc3..aa5c2e0 100644 --- a/sound/pci/via82xx.c +++ b/sound/pci/via82xx.c @@ -1746,6 +1746,12 @@ static struct ac97_quirk ac97_quirks[] = { }, { .subvendor = 0x1019, + .subdevice = 0x1841, + .name = "ECS K7VTA3", + .type = AC97_TUNE_HP_ONLY + }, + { + .subvendor = 0x1019, .subdevice = 0x0a81, .name = "ECS K7VTA3", .type = AC97_TUNE_HP_ONLY

2 1

[alsa-devel] sw parameter boundary
by Norbert van Bolhuis 26 Jun '08

26 Jun '08

is the boundary sw parameter still used ? where is it for ? in the PCM kernel core (e.g. snd_pcm_playback_avail) it clearly serves as a pointers wrap point, but which one ? The one at the end of the DMA buffer or the one at the end of a process (virtual) address range (4 GB) ? -- This message has been scanned for viruses and is believed to be clean

2 4