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

Re: [alsa-devel] [PlanetCCRMA] drop outs with FC8 and latest CCRMA kernel
by John Dey 04 Jan '08

04 Jan '08

Hector, I have read your response and can only comment that I have been a user of CCRMA's version of Fedora for some time. I am not responding to place my recommendation for that distribution over Ubuntu since I only tried Ubuntu early on when it was not stable. I would like to offer my observation on what I have felt for a long time regarding to multimedia (sound) on linux. What has made linux OS so successful is that it has a legion of volunteers willing to contribute to the cause of advancing the state of the OS for free but even more importantly, in my opinion, is the fact that Linus Torvalds has been the leader to keep those volunteers motivated while controlling/coordinating the development of the OS. He and others (what were very productive volunteers) have even figured ways to make a living at what they have done so well for free. I am unaware of any such individual (or organization) functioning similarly for multimedia-sound). My reason for choosing CCRMA and staying with it is because Fernando Lopez-Lezcano has been available, almost at moments notice, to answer and solve most of problems that I have encountered. (I don't know how he has the patients and stamina to do what he does.) I do get frustrated that I can not get my ATI graphics card to work and have to settle for a less then optimal driver for video but my major concern recently, and maybe I am wrong, is the state of soundcard drivers available for linux (particularly notebooks). I have had good luck with desktops and m-audio soundcards but with notebooks I don't have any comfort that there are cards that fully work. (This comment maybe too harsh.) Without reliable soundcard drivers, I worry that the whole elegant alsa sound system and sound applications my never achieve their full potential and may just wither and die. I have heard some of the arguments that vendors have been non-cooperative. I do believe that there should be ways to structure an approach that would give the linux/sound community leverage over the vendor in order to get their cooperation, e.g. a non-profit organization with support from colleges and university music departments. I would like to hear if I am all wet. However, before we get too far into the new year, I had to get these thoughts off my chest. Happy New Year? And thanks to all who contribute. John Dey On Jan 4, 2008, at 10:12 AM, Hector Centeno wrote: > Hi again, > > > On Jan 3, 2008 9:04 PM, Lamar Owen <lowen(a)pari.edu> wrote: >> On Thursday 03 January 2008, bH wrote: >>> Lamar Owen wrote: >> >> The point is, once built for Ubuntu 7.10, it has to be rebuilt for >> 8.04, then >> 8.10 (or whatever), and so on; you don't gain anything going to >> Ubuntu, as it >> is just as fast moving as Fedora is in terms of support; the repo >> would still >> have to be rebuilt every six months, as packages for 7.04 may or may >> not work >> for 7.10 (and packages for 6.06 will definitely not work for 7.10 or >> the >> upcoming 8.04). >> > > I think I disagree about this. You would gain a lot going to Ubuntu > instead of Fedora. It is true that Ubuntu gets upgraded every 6 months > (as Fedora does) but in Ubuntu you have the hard work of many people > trying to make Linux usable and friendly and at the same time to keep > it up to date, while in Fedora you get a bunch of experimental and > broken things thrown to the users for beta testing. For instance, > something like having and ATI graphics card working, with full 3D > rendering, under Fedora 8 is almost impossible, while in Ubuntu works > out of the box, or if you want to install the Nvidia drivers in Ubuntu > you just get them from the repository or better yet, just click on the > proprietary drivers icon that pops up at the panel bar when it detects > your Nvidia hardware. I know I could just download the sources and > compile myself... but well, it saves time to have things planed ahead > by someone who cares about usability. > > Regarding the upgrading issue, I do mind having the latest version of > Gnome, for example, as it usually means less bugs and better > usability. As I said before, I think Linux-Audio and > Linux-as-a-desktop is quite young and in development, you can't really > get stuck with a buggy and underdeveloped application for too long as > you might be missing a stabler and more usable system. > > Just my thoughts. > > Cheers! > > Hector > > > >> But all of that is moot; PlanetCCRMA is currently an RPM repository, >> and the >> effort required for changing to be a Debian repository is significant; >> probably a lot harder than keeping up with Fedora (this is something >> I know a >> little bit about; I packaged PostgreSQL RPM's for Red Hat Linux and >> Fedora >> from 1999 up through 2004; I investigated Debian packaging, and it is >> very >> very different from RPM packaging. Now, nando is a very bright >> fellow; I >> have no doubts he is capable to doing that. The bigger question is >> whether >> he wants to do so. >> > > > > >> Further, there are already Debian packagers for some of this; you >> should >> really talk to them about updating their versions, rather than muddy >> the >> currently well-unified repository waters for Ubuntu. That is really >> the >> major advantage over Fedora that Ubuntu has; Fedora's repositories >> have >> historically been somewhat fractured. >> >> However, there is work ongoing to merge PlanetCCRMA RPM's into Fedora >> itself, >> which would lessen nando's work load. This I'm sure he looks forward >> to! >> >> Now, the latency could be due to other things set up in the >> PlanetCCRMA kernel >> and other libs versus the Ubuntu linux-rt kernel; don't know. It >> would be >> interesting to see what the .config for the Ubuntu rt kernel looks >> like >> versus the PlanetCCRMA one. >> >> I myself am having issues with the F8 PlanetCCRMA rt kernel; I'm >> running F7 on >> my main DAW desktop for now, but will be upgrading probably next >> week, as >> things are stable enough at this point for my uses. I'll probably >> forgo the >> rt kernel for now, as my uses currently don't require the low latency. >> >> I for one am thrilled with what nando has been doing for the last >> several >> years; many thanks, nando! >> -- >> >> Lamar Owen >> Chief Information Officer >> Pisgah Astronomical Research Institute >> 1 PARI Drive >> Rosman, NC 28772 >> (828)862-5554 >> www.pari.edu >> >> _______________________________________________ >> PlanetCCRMA mailing list >> PlanetCCRMA(a)ccrma.stanford.edu >> http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma >> > > _______________________________________________ > PlanetCCRMA mailing list > PlanetCCRMA(a)ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma >

1 0

[alsa-devel] posting
by Steve Thornley 04 Jan '08

04 Jan '08

What is appropriate. Especially, right now I'm trying to get my 5.1 system to work as something other than a 2 speaker set. looking for help, compiled from source last night ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

1 0

[alsa-devel] Cross compiling alsa-lib
by Adrian McMenamin 03 Jan '08

03 Jan '08

Is there anyone here able to give a canonical statement on how to configure alsa-lib for a cross compiled build linked to uclibc? I think the issue may be getting the path right for the libraries on the host machine.

1 0

Re: [alsa-devel] snd-hda-intel support for SPDIF-in wiht vt1708 card?
by Takashi Iwai 02 Jan '08

02 Jan '08

At Thu, 20 Dec 2007 10:13:29 -0800, John Stile wrote: > > On Thu, 2007-12-20 at 12:09 +0100, Takashi Iwai wrote: > > At Thu, 20 Dec 2007 00:37:46 +0000, > > forumjunk(a)comcast.net wrote: > > > > > > > > > For VIA platforms, to avoid the driver compile error in pci.h, reconfigure your kernel to remove SMP support, and set the architecture type to PC-compatible. > > > > > > (you already know this, I'm sure): > > > Recompile the kernel (as a paranoid, I always trash /lib/modules/<kernel_version> before making modules_install). Install the kernel, of course, and reconfigure your boot loader and/or initrd and reboot. > > > > > > There are still several fixes that need to be made to get all of this to compile cleanly, but I haven't got the permanent fixes nailed down yet. I'm almost positive that these are alsa-driver configure errors or omissions. I can't (yet) find a kernel config that will avoid them. The fixes below are harmless, and they will allow you to get the driver compiled. > > > > My guess is that the error of configure script is the only point we > > need to fix. > > > > > Add this definition to the top section of acore/memory_wrapper.c after the line that reads #include <linux/version.h> > > > > > > #define VMALLOC_VMADDR(x) ((unsigned long)(x)) > > > > > > Change these lines (45 and 46 or close to that) of acore/memory_wrapper.c from: > > > > > > pmd = pmd_offset(pgd, lpage); > > > pte = pte_offset(pmd, lpage); > > > > > > to > > > > > > pmd = pmd_offset((pud_t *)pgd, lpage); > > > pte = pte_offset_kernel(pmd, lpage); > > > > > > The driver will then compile cleanly (at least with no errors or warnings relating to any of these changes) > > > > Don't do this. This part shouldn't be compiled at all for recent > > kernels. This is, again, the problem of configure script that > > detected the codes wrongly. > > > > > > So, could you guys show config.log? Otherwise it's hard to know > > what's really wrong. > > > > > > thanks, > I recompiled the kernel without SMP support, and as PC-compatible (per > forumjunk(a)comcast.net). In config.log, vmalloc_to_page shows a warning > starting at line 540. "function cpuid_count causes a warning: pointer > targets in passing argument 4 of 'native_cpuid' differ in signedness". > --------------------------------------- > The config.log Thanks. Does the patch below fix the probelm? Run hgcompile after applying it. Takashi diff -r 414b1156a8b3 configure.in --- a/configure.in Tue Dec 18 16:09:20 2007 +0100 +++ b/configure.in Fri Dec 21 12:10:53 2007 +0100 @@ -1230,7 +1230,7 @@ esac dnl set ia32 (X86) case "$processor" in - i?86*|k?|crusoe|mcyrixiii|mwinchip|viac3_2|mcore2|geodegx*) + i?86*|k?|crusoe|mcyrixiii|mwinchip|viac3_2|mcore2|geodegx*|x86_32) if $KCC -mpreferred-stack-boundary=2 -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then c_opts="-mpreferred-stack-boundary=2 $c_opts" CONFIG_X86=y

2 5

[alsa-devel] ALSA HDA problem with 64-bit kernels
by Timo Jantunen 01 Jan '08

01 Jan '08

Heip! I recently moved to 64-bit kernel, but mixed sounds (ie. mpegs played with a media player) don't work with optical S/PDIF connection. AC3/DTS passthrough still works, and I can hear the mixed sounds on analog connector. And yes, I have unmuted the IEC958 mixer setting. Tested kernels: ALSA 1.0.14: 2.6.23.1 32bit: works 2.6.23.1 64bit: broken 2.6.23.12 64bit: broken 2.6.23.12 64bit kernel, 32bit userspace: broken ALSA 1.0.15: 2.6.24-rc6 64bit: broken (and half of the mixer settings are missing) The soundcard is integrated to the motherboard (Abit IP35 Pro) and I can't find any more information on it than it is "7.1 CH HD Audio CODEC". Relevant part of dmesg (it is the same for 32/64 bit versions, expect that the interrput goes to IRQ 18): ===cut dmesg Advanced Linux Sound Architecture Driver Version 1.0.14 (Fri Jul 20 09:12:58 2007 UTC). ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 22 PCI: Setting latency timer of device 0000:00:1b.0 to 64 hda_codec: Unknown model for ALC883, trying auto-probe from BIOS... usbcore: registered new interface driver snd-usb-audio ALSA device list: #0: HDA Intel at 0xfdff4000 irq 22 ===cut lspci 00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 02) Subsystem: ABIT Computer Corp. Unknown device [147b:1083] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 22 Region 0: Memory at fdff4000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us ExtTag- RBE- FLReset+ DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us ClockPM- Suprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- Capabilities: [100] Virtual Channel Capabilities: [130] Root Complex Link ===cut asound/cards 0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0xfdff4000 irq 22 ===cut There are no differences in /proc/asound directory entries expect the cards file (different IRQ). Any ideas how to fix this? //T

1 0