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

[alsa-devel] Unknown card info
by Jorge Peixoto de Morais Neto 24 Aug '07

24 Aug '07

When I execute sudo modprobe snd_bt87x, I can't capture audio from my tv capture card (mencoder segfaults). It only works when I execute sudo modprobe snd_bt87x load_all=1. Then it seems to work ok. When I issue sudo modprobe snd_bt87x load_all=1, the following lines appear in dmesg: unknown card 0x878-0x1554:0x4011, 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> I am obeying the request and mailing this information to you. I have no idea what is the correct digital_rate option; all I know is that the default seems to work ok. I have a cable connecting the sound output of the tv card to the line in of my sound card; it seems that when wathing tv through mplayer this is the mechanism used (and it works ok). However, when recording tv through mencoder, it seems to use snd_bt87x (in fact, it does not work if snd_bt87x is not loaded), and it also works ok. The card option I pass when loading the module bttv is card=139. According to /usr/src/linux/Documentation/video4linux/CARDLIST.bttv, this corresponds to the card Prolink PixelView PlayTV MPEG2 PV-M4900 In fact, there is a sticker in the PCB that reads (if my eyes are not failing me) PixelView PV-M4900 FM.RC The full output of dmesg is attached to this email. If you need any additional information please contact me directly, since I will now unsubscribe to this list. Some possibly useful information: jorge@jorge ~ $ uname -a Linux jorge 2.6.22-gentoo-r3 #1 PREEMPT Tue Aug 14 18:51:06 BRT 2007 i686 AMD Athlon(tm) XP 2600+ AuthenticAMD GNU/Linux jorge@jorge ~ $ cat /etc/modprobe.d/tv options bttv card=139 automute=0 options snd_bt87x load_all=1 jorge@jorge ~ $ arecord -l **** List of CAPTURE Hardware Devices **** card 0: CMI8738MC6 [C-Media PCI CMI8738-MC6], device 0: CMI8738-MC6 [C-Media PCI DAC/ADC] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: CMI8738MC6 [C-Media PCI CMI8738-MC6], device 2: CMI8738-MC6 [C-Media PCI IEC958] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: Bt878 [Brooktree Bt878], device 0: Bt87x Digital [Bt87x Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: Bt878 [Brooktree Bt878], device 1: Bt87x Analog [Bt87x Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 jorge@jorge ~ $ sudo lspci Password: 00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge 00:01.0 PCI bridge: VIA Technologies, Inc. VT8235 PCI Bridge 00:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 00:0b.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 00:0b.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) 00:0c.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10) 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) 00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 MX 440] (rev a3) -- Software is like sex: it is better when it is free. --Linus Torvalds

3 3

[alsa-devel] Unable to open plughw:0,0 from user program.
by stan 24 Aug '07

24 Aug '07

Hi, I am unable to use plughw:0,0 as a device string while calling err = snd_pcm_open (&alsa_dev, hw_from_default, SND_PCM_STREAM_PLAYBACK, 0); The same call works with hw_from_default == 'default', but fails when it is 'plughw:0,0'. The error is cannot open audio device "plughw:0,0" (Device or resource busy) I am using the latest snapshot of alsa-lib, alsa-lib20070821. I tried debugging but I cannot trace through the macros. As near as I can tell there have been no changes to alsa.conf, and this worked just fine before the latest upgrade alsa package alsa-lib.1.0.14-3 Is this a deliberate change in alsa that is known about, and is there a way to still get the functionality? Thanks.

3 7

[alsa-devel] hw_params function and OSS emulation
by Timur Tabi 24 Aug '07

24 Aug '07

I'm working on an ASoC driver, and I noticed that with OSS emulation enabled, my snd_pcm_ops.hw_params and and snd_pcm_ops.hw_free are called multiple times when an OSS driver uses the OSS emulation. In my case, .hw_params is called *four* times, each time with a different DMA buffer size and number of periods. The problem is that my driver allocates a DMA buffer in my .hw_params function. For now, I have it deallocate the buffers at the top of the function and then allocate new ones based on the new hw_params values. This is really annoying. So I have a few questions: 1) Is there any way this can be fixed? Can't the OSS emulation code figure out what it needs and wait until it's done before it calls .hw_params? As a solution to the DMA buffer deallocate/reallocate hack I'm using, would it be okay to move the actual allocations to snd_pcm_ops.prepare()? My .hw_params function will collect the relevant data and keep them in some private structure. Then when .prepare() is called, I do the actual buffer allocation. 2) Can I assume that .prepare() is called only once? 3) Can I assume that .hw_params() is never called after .prepare() is called? -- Timur Tabi Linux Kernel Developer @ Freescale

3 20

[alsa-devel] Intel-HDA ALC262 (again)
by Andy 23 Aug '07

23 Aug '07

Alas, I spoke too soon. The headphone jack and internal speakers work as expected, until I adjust the main volume (labeled in alsamixer as 'front') at which point both the internal speakers and headphones play! Unplugging the headphones and reconnecting them makes everything OK again. Any ideas? (patch against 2.6.22 that makes my chip mostly work is attached). I guess that alc262_hippo_automute() needs to be called somewhere it isn't, but I couldn't see where. Thanks again! Andy >Yep, I'm happy to report that does indeed fix it! >Thank-you Takashi! :) >Andy. > At Wed, 25 Jul 2007 16:51:25 +0100 (BST), > Andy wrote: > > > > Hello again Takashi, > > > > I put in some printks, and indeed the function > does > > run and it correctly detects that there are no > > headphones present, but the speakers are not > unmuted. > > > > (the 'mute' variable both times is reported as > being > > 0x80 after it is set with snd_hda_codec_amp_read) > > Ah, it means that this intiailization gets called > before restoring the > mixer elements. Since sony model doesn't have the > mixer element for > the NID 0x14 that is linked with 0x15, 0x14 isn't > restored properly in > the end. > > How about the patch below? It's a bit too ad hoc, > but better than > buggy. > ___________________________________________________________ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/

2 3

[alsa-devel] I want to improve Sigma-Tel STAC9227 driver / How to implement support for multiple ADC
by Maxim Levitsky 23 Aug '07

23 Aug '07

Hello, I am a user of Sigma-Tel STAC9227 intel hda based chip. I have studied its documentation, and found that alsa driver doesn't support number of its features. 1) it has "analog loop-back" which means it can mix sound just before it enters ADC0 to output of DAC0 (headphones/front). For me it is the most important feature, since I have a tv card with analog output. 2) it has the ability to "swap" left/right channels, and this can be very useful for LFE/center channel 3) It has a VolumeKnob "widget" , that allows to decrease volume of all DACs _after_ their own volumes were applied, and I think I turn it to "master volume" Those things below aren't supported by windows driver ether, but that doesn't mean we can't support that :-) 4) this chip has 3 ADC, each capable recording from different source, but alsa uses only first. 5) I have 5.1 configuration, so DAC1 is unused. It is possible to connect it to "front" mic, and get 7.1 sound card I think about a option "Use front mic as output", for 3Stack configuration 1,2,3 are easy to implement, since those are just mixer switches. But I have a question about 4: Now the driver has buggy support for second ADC, it record from it, but fails to connect it to any input source, and unmute it. I can fix that and trivially add support for third ADC, but current driver makes all ADCs a sub-streams of a single PCM device. I think that sub-streams are meant to be used only by playback PCMs that have hardware support of mixing, so I feel that is is better to make each ADC to be a separate PCM device, with separate mixer controls (enabled/input source/gain), and I want to ask you whenever you agree with me. Also I noticed that dsnoop chokes on record streams with more that one substream, it fails with error, when I try to open second arecord. Best regards, Maxim Levitsky

2 4

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