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

[alsa-devel] soc.h macros
by Jon Smirl 26 Jul '08

26 Jul '08

Can you help me document these macros? For example what does TLV stand for? I know it supplies a decibel range. R really mean two registers. What does EXT do? How about S8? #define SOC_SINGLE(xname, reg, shift, max, invert) #define SOC_SINGLE_TLV(xname, reg, shift, max, invert, tlv_array) #define SOC_DOUBLE(xname, xreg, shift_left, shift_right, xmax, xinvert) #define SOC_DOUBLE_R(xname, reg_left, reg_right, xshift, xmax, xinvert) #define SOC_DOUBLE_TLV(xname, xreg, shift_left, shift_right, xmax, xinvert, tlv_array) #define SOC_DOUBLE_R_TLV(xname, reg_left, reg_right, xshift, xmax, xinvert, tlv_array) #define SOC_DOUBLE_S8_TLV(xname, xreg, xmin, xmax, tlv_array) #define SOC_ENUM(xname, xenum) #define SOC_SINGLE_EXT(xname, xreg, xshift, xmax, xinvert, xhandler_get, xhandler_put) #define SOC_SINGLE_EXT_TLV(xname, xreg, xshift, xmax, xinvert, xhandler_get, xhandler_put, tlv_array) #define SOC_SINGLE_BOOL_EXT(xname, xdata, xhandler_get, xhandler_put) #define SOC_ENUM_EXT(xname, xenum, xhandler_get, xhandler_put) SOC_ENUM("3D Function", wm8753_enum[5]), SOC_ENUM seems really inefficient tracking those enum numbers. Could you declare the enum in place? #define SOC_ENUM_SINGLE(xname, xreg, xshift, xmax, xtexts) \ { .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = xname,\ .info = snd_soc_info_enum_double, \ .get = snd_soc_get_enum_double, .put = snd_soc_put_enum_double, \ .private_value = (unsigned long) &(struct soc_enum) \ .reg = xreg, .shift_l = xshift, .shift_r = xshift, \ .max = xmax, .texts = xtexts } Is it possible to turn all of these macros into inline functions? Can an inline initialize a structure? Making them inlines would get us syntax checking without expansion. I'm having some success getting 32b wide controls working. -- Jon Smirl jonsmirl(a)gmail.com

2 1

Re: [alsa-devel] alsa-lib has anyone ever looked at taking it cross platform?
by Peter Dolding 26 Jul '08

26 Jul '08

> Peter Dolding wrote: >> Pulseaudio and all other Sound Servers since its a extra service adds >> a extra point of complete sound failure to the Linux sound stack or >> what ever stack they happen to be operating on top of. It more of a >> hack around the limitations of the alsa framework. ALSA was really >> designed to avoid the need of such extras. The existence of >> Pulseaudio is really sign of failure. Reason Sound Servers existed at >> first due to the failures of OSS to provide a multi application sound >> support. ALSA was really designed to do away for the need of sound >> servers completely. Now alsa is failing to provide per application >> sound control and a sound server is back for another pass. > > I really don't see why the existence of sound servers is a failure of > ALSA. ALSA does it's job very well by providing the necessary hardware > drivers and an interface to them. The kind of things needed by a modern > desktop sound system, however, goes way beyond the 1:1 hardware interface. > > At the most basic level, sound servers can be reduced to just software > mixers. The name "sound server" has a very bad reputation that (these > days) is not deserved. To say that pulseaudio's existence is a failure > of ALSA is doing ALSA a massive disservice. Sure, the software mixing > can be done by Alsa's DMIX but DMIX is just a "sound server" anyway, so > what specifically makes DMIX better or worse than PA in this regard? > Because DMIX is started automatically? Because it's in kernel space? > None of these arguments hold up when you get involved at the level of a > distribution who packages things together correctly. > > Pulseaudio is just a name and the kind of things it does are very much > different to the core goals of ALSA (with the exception of the obvious > overlap between DMIX and PA). The two fit very well together IMO. Same line OSS used just with a few words changed Pulseaudio with ESD and ALSA with OSS. You are repeating history and don't even know it. > > If it makes you feel any better, just call pulseaudio "ALSA Desktop > Services". Like I say it's only a name! > Its a failure renaming failure does not change it. Over time you get more and more competing sound servers. How long before people of PA look at ALSA and go why in hell are we using that nasty thing and just go straight around alsa-lib and straight to alsa drivers so we don't have the performance bottle neck. This is exactly what PA is trying to do now you will talk straight to us so you must run PA. One everything is talking to PA they can go direct to hardware. No matter if it causes trouble or not. DMIX is userspace and was alway designed that ALSA could be expanded to take on any task. The difference is 1 sound server. Total 1. No more does OS need. ALSA was designed to be Linux's Sound Server and all the other low level sound parts. As soon as you have more you have trouble. PA is a second sound server that just provides a second point for sound failure. Basically PA should not exist. If alsa was interesting in being just hardware only DMIX did not have to be created we could have just linked to ESD and other sound servers of the time. DMIX is a clear sign that ALSA is ment to be far more. PA is a intruder everything PA is ALSA should be as well. PA is taking the wrong method to fixing the the MIX problem DMIX should have been upgraded. > >> Now if you want to keep on thinking along that line has ALSA got to >> the point it should be dumped like OSS has been dumped because of its >> limitations? > > Of course ALSA should not be dumped! ALSA does it's job very well, and > PA does it's very well too. I really don't see how you got to that > statement from what I said. PA doesn't try and reimplement ALSA, it just > implements the higher level audio stack. > >> alsa-lib to freebsd or somewhere with oss most likely could be done >> really quickly since we already have a oss output option. >> >> Its also like saying the Linux Standard Base is only used by Linux. >> Its not its also used by a few non Linux's. Driver section of ALSA >> most likely will always be Linux only. But the wrapper layer that >> hides the hardware from the software really does not have to stay >> Linux only. Alsa is going up to be part of the Linux Standard Base >> its about time we all start looking at how it can be made most useful. >> Provide all the features it should and work for stability. > > I've not programmed much with alsa lib but I do know it's not all that > simple. That's there are several other layers on top that exist. There > API is complex and powerful but it also open to a lot of abuse. There > are many ALSA client apps out there that are poorly written. That's > simply because the API is complex and it is easy to make mistakes that > do not surface with one setup but do on another. Making apps work nicely > with DMIX was a pain and as soon as you remove the hardware aspect of > the underlying system (e.g. to replace it with a plugin like bluez or > PA) lots of interesting issues come to the fore. > So it is like xlib. A wrapper lib that has got too complex for its own good. xlib also caused strange failures when connected to different brand X11 servers. xcb was all about simplifying a very complex process. Sound servers are also a way of avoiding have to fix these issues. Just like toolkits on X11 have been. If PA or ESD or any of the other sound servers can provide a simple usable API so should ALSA. Difference in operational complexity is 100 percent a error in ALSA. Of course more complex options can remain. Existence of sound servers is pointing to failures. I have not got onto the nasty bit of 3d sound not being simple inside alsa. Creative wanted to go straight past ALSA with openal. Somehow I think they should have been let destroy alsa completely if people here are not prepared to pull head out sand. Tidy direct hardware interface api is needed. ALSA-LIB need to be feature rich. It need to go cross platform so developers of PA, liboa and others get pulled in here. Or this will just rot and rot until the day comes that ALSA-LIB will have to be dumped because its no longer anything more than a processing black hole. One option if PA is so many time better. Is to complete save a lot of time and completely do way with ALSA-LIB and say to the PA guys here write a new direct interface to the drivers. Because that is what will happen in time if this project does not step up. The question is how many years. It is really a simple selection kill/let ALSA-LIB slowly die off or step up be a architecture and take PA and other sound servers on head on. If alsa-lib is not going to step up we might as well save the resources and focus them better. Really we do want all the sound server/driver/basic wrapper developers here. So there are more developer to deal with ALSA glitches. I think some people here have got way way too friendly with the completion. PA is not a save ALSA camp it is a long term kill bits of ALSA camp. Question is how far do they go before alsa starts protecting itself. Going cross platform is part of the protection. No reason to keep the sound system of linux segmented any more. ALSA was always ment to kill of the segmentation. Its currently failing nicely at that task. Peter Dolding

2 1

[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] alsa-lib has anyone ever looked at taking it cross platform?
by Peter Dolding 25 Jul '08

25 Jul '08

This would kinda make logical sence. Alsa-lib plugin system in theory should be able to take any kind sound output under it. Simplify development of all applications on top of it. If alsa was cross platform why would you use something else as a middle body wrapper when you port. Windows and Mac support could be done as plugins. Or is there something that is in the alsa-lib that is a problem? Its all about reducing distance between application and hardware and reduce amount of coding. Peter Dolding

3 2

Re: [alsa-devel] [PATCH 10/10] wss_lib: use wss detection code instead of ad1848 one
by krzysztof.h1＠poczta.fm 25 Jul '08

25 Jul '08

Rene Herman napisał(a): > >>>> Is this now done in generic code? Not necessary anymore? Was no > comment > >>>> in the changelog. > >>> The MODE_RUNNING is not used at all in the cs4231 code. I wonder what > the purpose of it. > >> It was used by the AD1848 code though; snd_ad1848_trigger() set/reset > it > >> on start/stop and it was then tested by snd_ad1848_interrupt() to > decide > >> whether or not to call snd_pcm_period_elapsed(). > > > > It is not used by the cs4231. The only difference is that ad1848 does > not > > call the snd_pcm_period_elapsed() after calling the snd_ad1848_open() > > but before calling the snd_ad1848_trigger() (and similar restriction > > after the snd_ad1848_trigger() and snd_ad1848_close(). > > > > The cs4231 does not use such restriction. I decided it does not really > matter. > > The interrupts are not enabled before and after the > snd_ad1848_trigger(). > > If the cs4231 driver needed this it would be already causing problems. > > It seems we are talking at cross purposes. I'm not talking about cs4231. > I see this MODE_RUNNING thing disappear from ad1848_lib and, unless I've > missed it, not resurface in wss_lib -- that library that after these > patches is used to drive AD1848 chips that used to be driven by > ad1848_lib. > > The MODE_RUNNING looks as something someone will have once added upon > seeing spurious IRQs and as such, testing that it isn't needed on > chip/card A, B and C doesn't tell us much. The problem may have been > observed on type D, E or F and/or under condition foo or bar. > > Looking at snd_wss_interrupt() I dom't seem to be seeing a similar guard > after these patches. > > If it's not needed, all for slashing it but please be convincing. Note > that by now you should know a lot more about the innards of this code > than I do, so please be as verbose as needed. > I cannot be convincing as I am not convinced myself. I understand your reasoning. My situation was that I saw the guard in the ad1848 which was missing in the cs4231 while they should look like twins (in the area when MODE_RUNNING existed). I had two choices: 1. Add MODE_RUNNING to the cs4231 2. Remove MODE_RUNNING The first approach is a bloat to me as I tested on ad1848 and it was not needed. I don't know the conditions you called the "condition foo or bar" and I don't know if it ever exists. I have checked git history on the file, but this one was added earlier. Maybe there was a kind of approach in the old days then dropped/replaced later (like mutex_open which is not needed now). The second approach is more dangerous but with enough testing should be justified and provides us with cleaner code. Regards, Krzysztof ---------------------------------------------------------------------- Te newsy nakreca Cie na caly dzien! Sprawdz >>> http://link.interia.pl/f1e94

1 0

Re: [alsa-devel] [PATCH] [alsa-utils] Fix build with library
by Bryan Hanks 25 Jul '08

25 Jul '08

Takashi, Here is the patch for alsa-utils not being able to compile against alsa-lib if certain features were disabled in the library. It uses AC_CHECK_HEADERS as you suggested. It disables midi or seq and alsactl (if either are disabled, since it makes use of rawmidi.h and seq.h) from the build. Bryan

1 0

[alsa-devel] Help
by Sudeept Prusti 24 Jul '08

24 Jul '08

Hi all, As i am working on ALSA for last few weeks.Can anyone guide where can i get moe informative things on ALSA internals (Internally how alsa works). Could anyone suggest what are validation scenario on alsa driver flow. Thanks a lot. Awaiting for response soon. Regards, Sudeept The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it. Contact your Administrator for further information.

2 1

[alsa-devel] [Fwd: Filling "Struct snd_dma_buffer" manually]
by dinesh 24 Jul '08

24 Jul '08

-------- Forwarded Message -------- From: dinesh <dinesh.dua(a)coraltele.com> To: alsa-devel <alsa-devel(a)alsa-project.org> Subject: [alsa-devel] Filling "Struct snd_dma_buffer" manually Date: Thu, 24 Jul 2008 18:29:59 +0530 Hello, I am stuck with a problem please help me. I have allocated a buffer in ram and i want that if i playback something from user end then alsa library exchanges data with this buffer using memory mapping but for this i have to fill a structure "snd_dma_buffer" in driver code but as i have told i dont want to use dma so i have to fill it manually with address of ram buffer. Please tell me if it is possible if yes then help me. Thanks in advance.. Regards, Dinesh Dua _______________________________________________ Alsa-devel mailing list Alsa-devel(a)alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

2 1

Re: [alsa-devel] [PATCH 2/2] Update Poodle to current ASoC API
by Mark Brown 24 Jul '08

24 Jul '08

On Thu, Jul 24, 2008 at 04:54:48PM +0400, Dmitry Baryshkov wrote: > Signed-off-by: Dmitry Baryshkov <dbaryshkov(a)gmail.com> > Cc: Richard Purdie <rpurdie(a)rpsys.net> > Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> > --- > This should probably go into 2.6.27, if possible I've queued this for Takashi, thanks (he's on holiday this week). I had thought that at least the second hunk was already fixed but it seems not. Please CC all ALSA patches to alsa-devel(a)alsa-project.org.

3 6

[alsa-devel] Filling "Struct snd_dma_buffer" manually
by dinesh 24 Jul '08

24 Jul '08

Hello, I am stuck with a problem please help me. I have allocated a buffer in ram and i want that if i playback something from user end then alsa library exchanges data with this buffer using memory mapping but for this i have to fill a structure "snd_dma_buffer" in driver code but as i have told i dont want to use dma so i have to fill it manually with address of ram buffer. Please tell me if it is possible if yes then help me. Thanks in advance.. Regards, Dinesh Dua

1 0