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

Re: [alsa-devel] [Alsa-user] Impossible to make subwoofer work on a Dell XPS M1710w
by Michael Gerdau 23 Aug '07

23 Aug '07

[crossposting to alsa-devel as adviced in ALSA-Configuration.txt] > The model option is _the_ important option for HD-audio driver. > It overrides the configuration preset. As default, the driver reads > the PCI (subsystem) IDs to identify which configuration preset to > use. If not found, the driver does a guess work from the BIOS setup > in most cases. > > Now, since many laptops are shipped with broken BIOS and the guess > work is imperfect, you often face the famous problem -- "sound > doesn't work" (great words that explain everything). Then you can > pass model option for the preset designed for anohter hardware > (e.g. model=thinkpad) to make the driver probe as if it's such a > hardware. If you are lucky, your device is similar with others, and > the driver works with such a preset. If not, we'd need to hack > another preset for matching with your device. > > The list of available model option is found in > ALSA-Configuration.txt. So it seems the Dell XPS M1710 isn't yet listed among the known models and also does not seem to be detected properly (as of hg20070816). 'lspci -v' gives: ... 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) Subsystem: Dell Unknown device 01ce Flags: bus master, fast devsel, latency 0, IRQ 21 Memory at efffc000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [70] Express Unknown type IRQ 0 Capabilities: [100] Virtual Channel Capabilities: [130] Unknown (5) ... 'lspci -nv' gives: ... 00:1b.0 Class 0403: 8086:27d8 (rev 01) Subsystem: 1028:01ce Flags: bus master, fast devsel, latency 0, IRQ 21 Memory at efffc000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [70] Express Unknown type IRQ 0 Capabilities: [100] Virtual Channel Capabilities: [130] Unknown (5) ... Anything else I could do to help getting it (fully) supported ? Best, Michael -- Vote against SPAM - see http://www.politik-digital.de/spam/ !tagline Michael Gerdau email: mgerdau(a)tiscali.de GPG-keys available on request or at public keyserver

5 15

[alsa-devel] Tascam US-428 USB Problems
by Michael Bourgeous 23 Aug '07

23 Aug '07

Hello, I hope this reaches the Tascam driver developer... I have a Tascam US-428 which worked great with my Athlon XP, but does not work at all with my new system, an Athlon 64 X2. I've tried using the regular alsa driver, as well as the hwdep audio, and jackd always crashes with a SIGSEGV, with the following message in the kernel log: [ 2538.003798] ALSA /home/nitrogen/src/alsa-driver-1.0.14rc3/usb/usx2y/usbusx2yaudio.c:148: should not be here with counts=42 [ 2538.003806] ALSA /home/nitrogen/src/alsa-driver-1.0.14rc3/usb/usx2y/usbusx2yaudio.c:91: active frame status -70. Most probably some hardware problem. n I did some searching through source code, and found that the frame status of -70 (ECOMM) indicates an OHCI buffer overflow error. As soon as the usx2y driver receives this it bails out of whatever it's doing, and jackd crashes. I've tried changing the usx2y driver to ignore such errors, and while there are audio glitches when such an error occurs, jackd no longer crashes and the audio keeps playing. This leads to question one: Is there any reason to bail out instead of trying to recover from errors? I've tried all the different USB ports on my motherboard, different USB cables, and running through a hub instead of a direct connection. None of these things helped. Though the usx2y message says "Most probably some hardware problem", I think this is something that is software related, as other USB devices have no problems. So here is question two: what kinds of problems, software or hardware, would lead to a buffer overflow error, and can I fix this in the driver code? Thanks, Mike Bourgeous

2 6

Re: [alsa-devel] ESI reply!! (MAYA44 datasheet request)
by Claus Riethmueller 23 Aug '07

23 Aug '07

Hi James, please let me say first that I am not intending this as any personal comment as I am pretty sure you are not the only person with similar thoughts about the discussion. Yet, I have to say that it is exactly the somewhat ignorant attitude that turns us and quite a number of other vendors "off" in supporting the ALSA developer community better. It is what I have refered to in my email to Piotr that he cut & pasted to this mailing list (without asking for permission btw.). I have been following the developments at ALSA since many years now and worked with a number of different developers for different products to get them working properly. Many of our products are supported just fine under ALSA and both the developers and the users seemed to appreciate that fact. Unfortunatly your comments show your obvious lack of understanding about how some companies are working in this industry and what sort of approach is needed by you guys to get better support from us. This is why I used the term "culture crash" in my email. > So, basically, ESI cannot help us. > I am amazed that they can write any sort of driver without some sort of > datasheet. Well ... frankly, it should not be your concern on how we are developing drivers for our hardware designs (which are ours). What you wrote is a cheap comment and I do not see how it could be an appropriate comment if you look at everything what I wrote and not just the introduction. The way (format, style and most important in our case: language) we store our internal company data is no ones concern except mine and the concern of my employees. We are not developing our products with the purpose to share this information with others. It is not part of our business model. We are not a chipset vendor and we are not making designs that other companies are supposed to use or work with. Our data is used inside our company and nowhere else. Every document that goes out to the public must go through a process that is aprooved by a number of people, written by the actual responsible person, in our case partially even translated into another language by someone who is not an expert on the issue and only then could be sent out. Unless we have to do that to achieve something we want to achieve, we simply can't do that. This might be different with other companies you've been in contact with (I saw you developed major parts of the drivers for various Creative devices and can probably guess that this is where main parts of your experience come from) where there are more people available that could get and go through such tasks. I could now add information about company and market sizes, etc. but that would make everything only more complicated (that's the type of discussion that is nice in combination with a few beers in a pub at some late evening ...). What I did in the introduction of my email to Piotr was to mention this fact about our situation without going into any details. I am probably saying more about how our company works than what many other vendors ever would disclose about themselve. I hoped it would help to improve the understanding of "the other side". Your comments are disapointing and puzzle me a little bit, but unfortunatly I have to say that I have expected something like this from my past experience. Luckily not all ALSA contributors / developers share your views as the fact that many of our products (as well as quite a number of products from other vendors) are supported in ALSA at this moment without having the document (you think) you need, speaks for itself I might add. > But I do know it does happen, because I have received datasheets that > were only written years after a particular sound card was first sold. > I would like to stress, that the datasheet does not have to be perfect. > We would be quite happy if it has spelling mistakes in, and some wrongly > labeled registers. > I have received datasheets from other manufactures where some engineer > has just scribbled some notes on the back of a piece of paper. At least you acknowledge that this happens which I think is quite positive. I am not saying that what you mention here resembles what goes on in our company, but it is not that far from the actual situation. If you add that our engineers are in Korea and make their notes mostly in Korea, you get a little bit closer to the real picture. Of course we have documents but they are not ready in any way that I would approove sending them out to the public. > Now, if ESI cannot even provide this, we should highlight ESI in RED in > the sound card matrix. As you can guess, it was this sentence that prompted me to reply directly to the list. In my opinion, your comment is unfair and simply ignoring major parts of what I wrote in my mail to Piotr. I have shown a certain level of commitment and your response basically tells me that you are not even interested ... if more people would share your views, ALSA would have made no development at all in the last 5 years I guess. Our engineers are all happy to answer questions and provide assistance and help if required. As I said, we are happy to be in contact with an individual developer who is actually doing the development. It is a lot less time consuming and for us a lot more simple (actually, I believe it is more simple for the developer on the ALSA end as well but I realize some people might disagree here). I'm sorry if this long mail has distracted a few people from the daily discussion about fixing bugs and improving code, but I am sure there are enough people that understand where I am coming from and what I wrote here. I do not want to start a long discussion here, so I also do not intend to comment on the whole issue further on the mailing list. Contact me directly and we can go from there (as I mentioned in my mail to Piotr). Best regards, Claus Riethmueller Managing Director ESI Audiotechnik GmbH

6 7

[alsa-devel] aplay giving underruns in non blocking mode
by Pharaoh . 22 Aug '07

22 Aug '07

Hi I am tesing my alsa driver for an arm based board. aplay works well when it is used in blocking mode, but I see underruns when I switch to non-blocking mode. What could be the reason? I have tried to remove all latencies in driver by using minimal locking etc, but it doesn't seem to make any difference. Also, the audio quality degenerates gradually in non-blocking mode. -Pharaoh.

1 1

[alsa-devel] ESI reply!! (MAYA44 datasheet request)
by Piotr Makowski 22 Aug '07

22 Aug '07

Hi Piotr, thank you very much for your email. The data sheet and information you request does not exist in any format that we could provide and frankly, we are way too busy with our normal work to prepare something like that in a way that would be of general use and would resemble what you require in your request. I am well aware of the general request and I know the text you sent us pretty well ... I have seen it many times before in various versions, usually copied via cut & paste and sent to us in one way or another ... and actually I am a bit tired of it. Unfortunatly we believe that the text and the way the request is sent to us is not really useful and not tailored at all to the special requirements that are common in this industry (pro audio / higher level sound card manufacturers) and that make this industry very different from your auverage computer component manufacturer. It's my personal experience, following the ALSA developer community for years, that this sort of basic cultural understanding is only slowly changing step-by-step but at a much slower pace than it could happen. Unfortunatly the majority of ALSA developers still seem to be "computer guys" and not "music guys" ... causing all sorts of problems that won't help to resolve the culture crash between the different parties. Most "music" companies work in a different way than typical IT companies. Our business are much smaller, and time of every single employee is extremly critical for us. I guess this all may sound ignorant to you, but please understand that I know what I am talking about to a pretty good extent (you can actually look up my name on the ALSA site where I am listed under contributors - http://www.alsa-project.org/main/index.php/ALSA_contributors - so I have experience on both sides). Again, we are happy to be in contact with the individual developer who is actually doing the development. If you volunteer to do the development yourself and/or if you know someone who would do it, please inform me and we can go from there. Please don't get me wrong, I understand what you want and where you are coming from, but this direct contact with the developer is a basic requirement for us - sorry. Best regards, Claus Riethmueller Managing Director ESI Audiotechnik GmbH

2 2

[alsa-devel] include/mixer.h missing from doxygen
by Rolland Dudemaine 22 Aug '07

22 Aug '07

Hi, include/mixer.h seems to be missing from the doxygen input file list. Should be added to the INPUT list in doc/doxygen.cfg. Btw, I'm pretty new do ALSA, why is the Mixer interface marked legacy in a couple places ? Best Regards, --Rolland Dudemaine

2 1

[alsa-devel] unknown card info [snd-bt87x]
by Vincent Minder 22 Aug '07

22 Aug '07

Hello, After loading the snd-bt87x module on my Fedora 7 x86_64 box, here is what I found in the dmesg output: unknown card 0x878-0xbd11:0x1200, using default rate 32000 please mail id, board name, and, if it works, the correct digital_rate option to <alsa-devel(a)alsa-project.org> The card is a rather old and cheap "PINNACLE systems - Studio PCTV rave" The chip on the board is from Conexant: CONEXANT Fusion 878A (chip markings: 25878-13, E32673.1, 0023 KOREA) The card standard is PAL B/G. I think this model supports only MONO audio. It has TV-in, Audio-out (mini jack), Composite-in, S-VIDEO-in. TV playback is working all right (tested with "kdetv" and "tvtime"). I have sound as long as I use the Audio-out connector and bridge it to my motherboard's integrated audio Line-in . However, I didn't manage to use the internal audio capabities of that board. So I have no clue about the "correct digital_rate". (I must admit I am not familiar with these technologies at all.) Here is the output of "arecord -l" regarding this card: $ arecord -l **** List of CAPTURE Hardware Devices **** (...) card 2: Bt878 [Brooktree Bt878], device 0: Bt87x Digital [Bt87x Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: Bt878 [Brooktree Bt878], device 1: Bt87x Analog [Bt87x Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 I am using the stock Alsa package of Fedora 7 x86_64 (fully updated distribution): alsa-lib-1.0.14-1.fc7 I hope this report will be useful to you. Sincerely, Vincent Minder (Belgium)

2 1

[alsa-devel] [PATCH] fix cmi8788 config (was: Re: [alsa-cvslog] alsa-lib: cmi8788: add alsa-lib config)
by Thierry Vignaud 22 Aug '07

22 Aug '07

Clemens Ladisch <clemens(a)ladisch.de> writes: > changeset: 2314:3bf9c6dec8c8 > tag: tip > user: cladisch > date: Wed Aug 22 09:42:13 2007 +0200 > files: src/conf/cards/CMI8788.conf > description: > cmi8788: add alsa-lib config > > Add a .conf file to enable dmix/dsnoop and softvol for CMI8788. > > Using dmix helps mask the bug that all audio is forced to 48 kHz. :-) as usual, here's the missing bit:

2 1

[alsa-devel] problems writing pcm driver
by Trent Piepho 22 Aug '07

22 Aug '07

I'm trying to write an ALSA driver, but there are some thing I'm not clear on and it's not working as well as I'd like. Atomicity: trigger, pointer, and ack are atomic with respect to themselves. e.g., two copies of the trigger callback can't be running at the same time. That much is clear. But are they atomic with respect to each other? Can the trigger callback run at the same time as the pointer callback? How about the atomic callbacks with respect to the non-atomic ones? Can trigger run at the same time as prepare? The pointer callback: What exactly is the current hardware position? My hardware has a counter that tells me how many periods have been DMAed into the buffer. Suppose my period size is 256 frames and I'm doing audio capture. If pointer is called before any DMA transfers have completed, do I return 0? Now suppose it's called after one period of audio has been DMAed into the buffer. Do I return 255 or 256? After two periods have been received, should I return 511 or 0? Why is pointer called so many times? Here's a log of callbacks and irqs my driver is getting. I'm using the cycle counter to give them microsecond timestamps. My period is 256 frames at 48kHz, so each period is 5333 us. There are only two periods in the buffer. Time (us) | Callback or IRQ ---------------------------------------------- 0.000 trigger - start DMA 134.513 pointer - count 1, returned 0 160.254 IRQ - not calling snd_pcm_period_elapsed 5313.030 IRQ - called snd_pcm_period_elapsed 5318.808 pointer - count 2, returned 256 IRQ hander finished 5348.309 pointer - count 2, returned 256 10627.526 IRQ - called snd_pcm_period_elapsed 10633.075 pointer - count 3, returned 0 IRQ hander finished 10659.755 pointer - count 3, returned 0 15941.173 IRQ - called snd_pcm_period_elapsed 15946.601 pointer - count 4, returned 256 IRQ hander finished 15969.743 pointer - count 4, returned 256 [and so on] The pointer callback is called only 134 us after the trigger, before the first IRQ or a period of data could possibly be received. Why is this done? To get the position in the buffer to start at? I assumed the data should start at the beginning of the buffer, but is this not the case? You'll notice the first IRQ is received at only 160 us. The hardware generates an IRQ when each period _starts_, not when one ends. So the first IRQ is ignored, the second IRQ tells me the first period has finished, and so on. The hardware counter is the number of periods started; I have to subtract one to get the number of periods finished. When the IRQ handler calls snd_pcm_period_elapsed(), that calls the pointer callback. That's what I expected from what the docs said. But about 30 us after the pointer callback is called the first time, after the irq handler has exited, it's called again. What is the purpose of this? Is it ok that I return the same value as the previous time it was called?

4 9

Re: [alsa-devel] ESI MAYA44 PCI datasheet request
by Ash Willis 22 Aug '07

22 Aug '07

Hi Piotr, In general, I think this is good. Some points though... * I don't think you should demand firmware source. Asking for that might be seen as quite invasive. It might be a bonus to have, but I don't see anyone hacking on it. Their firmware works, It's a driver that we need. Does this card even use firmware? I guess... * Linking to a mirror probably isn't too smart if they think their infos are going to distributed all over the web. Sorry, that was my fault. I'm an idiot. I think the correct link should be http://www-old.alsa-project.org/alsa/ftp/datasheets/ * I would offer a fall back. I would propose that the approach you have mentioned is in their best interest however if they are unwilling to distribute the information freely, then the next best thing would be to find one developer that is able, willing and possesses the hardware. That's not ideal. I would prefer the second approach to no driver at all, as would you, I'm sure. However, I don't speak for anyone else when I say that. * I'm sure they know the ins and outs of open source but you should confirm with them the terms of this arrangement. NDAs are basically incompatible with this whole thing because, usually, releasing the source will breach the NDA. Make sure they know that the driver being produced is open source and licensed under the GNU GPL. Ash > ----- Original Message ----- > From: Piotrek <oponek(a)gmail.com> > To: alsa-devel(a)alsa-project.org, "Pawe³ Wolniewicz" <admin(a)linux-muzyka.ixion.pl> > Subject: [alsa-devel] ESI MAYA44 PCI datasheet request > Date: Tue, 21 Aug 2007 19:50:27 +0200 > > > I would like toshow you the letter that I am going to send to the ESI > company. I am asking you to accept this letter because I am going to send it > on behalf of the ALSA development team. Any suggestions will be welcome. > > > Dear Sir/Madam, > > In reply to the letter sent 14.07.2007: > > 2007/8/14, ESI UK Support <uksupport(a)esi-audio.com>: > > Dear Piotr > > ESI do not provide and have no plans for Linux drivers for our products > However > ESI are happy to provide /share information to an Individual developer > within the Linux community > That is able and capable to develope drivers > and wishes to develope drivers > > Regards > UK Support > ESI Auditechnik > > > > I would like to ask you to share the information about ESI MAYA44 PCI card > needed to write drivers on behalf of the ALSA development team. ALSA team > needs all the information that you give your programmers to create drivers > for the device. We would like to ask you for: > > - a full datasheet containing IO port layout, register descriptions and > commands, > - ESI MAYA44 PCI firmware, > - EIS MAYA44 PCI firmware source code, > - permission for the firmware to be distributed with ALSA, > - source code for currnet windows drivers would be very helpful but isn't > essential. > > There are many peope that are willing to write the driver for MAYA44 and > because of the way Open-Source software and drivers are developed, in the > interest of it's quality, it is important that the information about the > card are accesable for all of the ALSA developers. We ask for your permision > to place that information on the ALSA server for developers. Thanks to that > any qualified person will have acces to it. Many other companies provided > that kind of information to us this way before: > http://ftp.mj2.org/pub/alsa/datasheets/ > > I am sure that adding this card to the list of the suported cards under the > linux operating system will cause the number of satisfied ESI card users to > increase. Thank you for your co-operation. > > > -- > Best Regards, > Piotr Makowski > ALSA Development Team > _______________________________________________ > Alsa-devel mailing list > Alsa-devel(a)alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > ----- Original Message ----- > From: Piotrek <oponek(a)gmail.com> > To: alsa-devel(a)alsa-project.org, "Pawe³ Wolniewicz" <admin(a)linux-muzyka.ixion.pl> > Subject: [alsa-devel] ESI MAYA44 PCI datasheet request > Date: Tue, 21 Aug 2007 19:50:27 +0200 > > > I would like toshow you the letter that I am going to send to the ESI > company. I am asking you to accept this letter because I am going to send it > on behalf of the ALSA development team. Any suggestions will be welcome. > > > Dear Sir/Madam, > > In reply to the letter sent 14.07.2007: > > 2007/8/14, ESI UK Support <uksupport(a)esi-audio.com>: > > Dear Piotr > > ESI do not provide and have no plans for Linux drivers for our products > However > ESI are happy to provide /share information to an Individual developer > within the Linux community > That is able and capable to develope drivers > and wishes to develope drivers > > Regards > UK Support > ESI Auditechnik > > > > I would like to ask you to share the information about ESI MAYA44 PCI card > needed to write drivers on behalf of the ALSA development team. ALSA team > needs all the information that you give your programmers to create drivers > for the device. We would like to ask you for: > > - a full datasheet containing IO port layout, register descriptions and > commands, > - ESI MAYA44 PCI firmware, > - EIS MAYA44 PCI firmware source code, > - permission for the firmware to be distributed with ALSA, > - source code for currnet windows drivers would be very helpful but isn't > essential. > > There are many peope that are willing to write the driver for MAYA44 and > because of the way Open-Source software and drivers are developed, in the > interest of it's quality, it is important that the information about the > card are accesable for all of the ALSA developers. We ask for your permision > to place that information on the ALSA server for developers. Thanks to that > any qualified person will have acces to it. Many other companies provided > that kind of information to us this way before: > http://ftp.mj2.org/pub/alsa/datasheets/ > > I am sure that adding this card to the list of the suported cards under the > linux operating system will cause the number of satisfied ESI card users to > increase. Thank you for your co-operation. > > > -- > Best Regards, > Piotr Makowski > ALSA Development Team > _______________________________________________ > Alsa-devel mailing list > Alsa-devel(a)alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > -- We've Got Your Name at http://www.mail.com ! Get a FREE E-mail Account Today - Choose From 100+ Domains

3 2