Linux-audio-user

linux-audio-user@lists.linuxaudio.org

3 participants
20662 discussions

[linux-audio-user] RME Hdsp PCMCIA problems

by D. Sen

I am wondering if someone knows how to fix this problem. When I insert the RME hdsp pcmcia card (interfaced to a multiface box) and type 'modprobe snd-hdsp', I get the following on /var/log/messages: Sep 27 20:50:57 localhost kernel: __alloc_pages: 9-order allocation failed (gfp=0x20/0) Sep 27 20:50:57 localhost kernel: __alloc_pages: 9-order allocation failed (gfp=0x21/0) Sep 27 20:50:57 localhost kernel: __alloc_pages: 9-order allocation failed (gfp=0x20/0) Sep 27 20:50:57 localhost kernel: __alloc_pages: 9-order allocation failed (gfp=0x21/0) Sep 27 20:50:57 localhost kernel: RME Hammerfall DSP: no buffers available Sep 27 20:50:57 localhost kernel: RME Hammerfall-DSP: no cards found lspci shows the RME card: 03:00.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall DSP (rev 0a) /etc/pcmcia/config.opts has: include port 0x100-0x4ff, port 0xc00-0xcff include memory 0xc0000-0xfffff include memory 0xa0000000-0xa0ffffff, memory 0x60000000-0x60ffffff include port 0xa00-0xaff exclude irq 4 exclude irq 7 Any help will be much appreciated. Thanks, DS

21 years, 1 month

[linux-audio-user] MIDI on alsa with SBLIve

by Laura Conrad

Timidity is practically unusable with Alsa on my box. In other ways it's only slightly creaky (it's a 3-4 year old AMD 755 box). But there are too many dropouts when I play a multichannel MIDI file for me to use it to proofread my publishing. (Under OSS timidity was fine, but regular readers may remember, my OSS broke when I upgraded to kernel 2.4.26, and I could only get help fixing ALSA, so I'm running ALSA). So I'm trying to set up the hardware MIDI on the SBLive. I'm following the directions at <http://www.tldp.org/HOWTO/MIDI-HOWTO-10.html> and things look normal. When I run "playmidi -a score.midi", it looks like it's playing, but there isn't any sound. (Yes, the speaker is plugged into the right place.) I've looked at the mixer settings and don't see anything obvious to change. So can anyone give me any advice either about how to get the hardware synth to work or how to get Timidity to work better? One part of my score is a quarter note longer than the others, and I need to find out where this happens. -- Laura (mailto:lconrad@laymusic.org , http://www.laymusic.org/ ) (617) 661-8097 fax: (501) 641-5011 233 Broadway, Cambridge, MA 02139

21 years, 1 month

[linux-audio-user] choosing the right sound system

by Miernik

There are so many sound dameons/systems/drivers that I don't know which combination to choose. I need some advice. Here is my setup: I have machine tarnica which is a router mainly, no monitor, no keyboard, but it has (my only) speakers. And I have machine szrenica (my laptop) where I run a jabber client, and I want it to notify me about messages through the speakers connected to tarnica. And on machine tarnica I have a radio card, and I want to record a regular radio program through it's soundcard with cron (I mean something started with cron). And sometimes like to play ogg files through tarnica speakers. What would be best set of daemons/apps/whatever to make all this work without coliding with each other and without the need to kill something to record from the radio and to be able to get jabber sound notifications no matter what else I do with the soundcard (without using killall). -- Miernik _________________________ xmpp:miernik@amessage.info ___________________/__ tel: +48888299997 __/ mailto:miernik@ctnet.pl Protect Europe from a law-disaster. Petition for a Software Patent Free Europe http://www.noepatents.org/index_html?LANG=en

21 years, 1 month

[linux-audio-user] [Announce] jack_snapshot

by Florian Schmidt

Hi, i just scratched an itch i had for some time. A command line based small and simple utility to store/restore jack connection states. Thus i release this initial [hack] version. Maybe someone else finds it useful. http://www.affenbande.org/~tapas/wiki/index.php?jack_snapshot flo

21 years, 1 month

[linux-audio-user] Agnula/Demudi server problems?

by Bill Morgan

I've received no mail from the Demudi list since Wednesday, and the Agnula and Demudi web sites aren't available. Anyone know the story? Thanks, Bill

21 years, 1 month

[linux-audio-user] AC97 Compliant cards that do not resample to 48khz when playing CDs (maybe slightly OT)

by Louis Lam

Hello All, Just out of curiousity, are there any AC97 compliant cards that does not resample everything to 48khz? I've read about this problem on SBLive cards. Lately I've been looking through many older sound cards e.g creative vibra, turtle beach montegro(au8820b2). Most of them have an ac97 compliant codec chip on board. Does it necessarily mean that the presence of this chip conclude that it will try to resample at 48khz? Some cards have another codec on board, e.g. the "Gainward Hollywood@home" (which by the way my system was able to detect and kind-of works, alsamixer and all, but have not use the advanced features yet)has an additional cs4341A-RS codec which handles the last 2 channels that the VIA VT1616(ac97, chan1-6) does not. Given that, how do you: 1. Find out whether the line-in/mic-in can use another codec, will it be: (A)hardwired by design or (B)can it be changed through alsa configuration e.g ".asoundrc" to do that. 2. If it is in the case of (A), then it sounds like to best choice is to record at 48Khz, mix then downsample to 44khz when you want to burn to CD. If this is the case, how will this downsampling affect the quality of the sound? Is there any way to overcome or improve it? Thanks very much, Louis ________________________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html

21 years, 1 month

[linux-audio-user] tuning freaks

by Dave Griffiths

Hi all, I'm confused, which of the 3000 scales here is the boring standard western one?: http://www.xs4all.nl/~huygensf/doc/scalesdir.txt I've just added scala (http://www.xs4all.nl/~huygensf/scala/) support to my sequencer, and as much as I like playing in the scale of "Empirical Tibetian Ceremonial", I'd quite like to jam with people :) cheers, dave

21 years, 1 month

[linux-audio-user] Re: es1370 latency and jackd, late driver wakeup

by Louis Lam

Hi All, No reply so far to this post, but its alright... maybe you guys are busy. I was thinking of two possibilities of why this is happening: 1. The Soundcard itself: I'm not sure whether the card can take the polling period of 2 by design. Couldn't find any previous post on this. 2. The Driver. But I've not seen any report on this in the linux-audio-users or alsa list. Can this have impact on the late driver wakeup issue? Thank you guys, my experience in Linux Audio has been pleasant so far. Many Thanks, Louis --- Louis Lam <lshoujun(a)yahoo.com> wrote: > Hello All, > > I have a bunch of old consumer sound cards. SBLive, Vibra128 and ensoniq 1370(es1370). I went > through quite a number of rounds trying out these cards and found that IMHO the es1370 gave me > the > best sound amongst these cards. So i went ahead and try to start jack according to the > capabilities of this card. > > With this card, i find that once i start jackd like this: > > jackd -v -R -d alsa es1370 -r 44100 > > I get lots of xruns immediately. > > Then i tried with the n=4 (ie 4 periods per hardware buffer), i.e "jackd -v -R -d alsa es1370 -n > 4" and I am able to get rid of the xruns. But i see lots of "late driver wakeup: nframes to > process=2048" on the jackd output. What does this message mean? > > For recording into ardour, n=4 and the default frames per period (1024) gives me quite > significant > latency when recording. e.g when I pluck a note on the electric bass i can hear it on the > line-in > monitor first and then from the capture slightly later. > > As a compromise, i set the frames per period to either 64, 128 or 256. But I still get the > "late > driver wakeup" message and occasional xrun when i quit ardour or sometimes even hydrogen. I > notice > that when quitting jackd programs there will sometimes be a few xruns. Is this normal? > > Seems like ideal to start n=2 but this card don't seem to allow me to do that. I could be wrong > but i think for low latency n=2 is ideal. > > If i have saved an ardour project with Tim Goetze's plugin activated in some tracks, ardour may > report that it is too slow or (something like that) when i reload that project file. I suspect > this is to do with some ladspa plugins requiring low latency which my setup is not able to give. > > I know this card is old, but it does give a great sound. I used SBLive previously and don't seem > to have these latency issues (able to start jack with n=2). For owners of this card, any sound > advice to get the most out of it? > > > > Thank You very much, > Louis > > > > ________________________________________________________________________ > Yahoo! Messenger - Communicate instantly..."Ping" > your friends today! Download Messenger Now > http://uk.messenger.yahoo.com/download/index.html > ________________________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html

21 years, 1 month

[linux-audio-user] M-Audio Sonica/Ozone/MobilePre/Transit firmware loader now works

by Clemens Ladisch

Hi, it has been reported that the 2.6.8 kernel has fixed the handling of USB resets, so now it's possible to use a Linux firmware loader to get these devices to work. You can get the loader at <http://usb-midi-fw.sf.net/>. Best regards, Clemens

21 years, 1 month

Re: [linux-audio-user] Converting sample rate: failed...

by davidrclark＠earthlink.net

Hi Erik, As you can see, we made it back after chasing Ivan around. Luckily we saw nothing but a few drops of rain. I'm sure others here or close to those here must have had bad luck instead of good, and my sympathies go out to them. Thanks for your response. I applaud your enthusiasm, but it appears to me that you are laboring under some misconceptions and misunderstanding of what I have posted. Among the misconceptions is a serious one that should cause concern amongst those who use libsamplerate. ------------------------- Minor problems: A good portion of your recent post is aimed at something I never claimed. It appears to me that you are failing to distinguish between two cases: 1) Series in general; 2) Series which have been previously prepared, specifically frequency spectra which are band- limited and lowpass filtered. >From my earlier post on the current subject: "The reason is that I assume that the input is band-limited, and this is usually true for my own work. Not only is it band-limited, but usually also tapered in the frequency domain, i.e. already effectively lowpass filtered." >From your recent post: "Now I will admit that if the signal is already bandlimited filter many not be necessary, but that is a different matter all together." No, it is certainly not a "different matter altogether." Your quote was nearly all I was saying as you can easily see, except that in addition signals I use (as well as most that others use) are also normally effectively lowpass filtered. This is more restrictive than your assumption, so filtering is even less necessary than you admit it to be. Your elementary examples from undergrad engineering courses and attempt to rephrase what you claim I said don't apply to the situation I've described; they have nothing to do with what I've said and are true but irrelevant statements which cause me to wonder what it is that you are trying to prove; you may want to give some thought to that: What is it that you are actually trying to prove or demonstrate to everyone? As a very minor note, you are also attempting to answer an ontological question (that something which has no observable effect on the universe can nonetheless be said to exist) which has plagued philosophers for millenia by merely declaring your opinion as fact. Here is what I actually wrote: "If nothing was removed or even altered, then no filtering has actually occurred." Note that I am not so reckless as to claim anything regarding existence or nonexistence here. ------------------------- ** Serious misconception **: Two paragraphs from your recent post: "If you work out the mathematical expression for your frequency domain converter, you will find that there is a time domain expression that is mathematically identical and that the time domain expression is in part a FIR lowpass filter very much like my converter." (You mean your implementation of Smith's converter, don't you?) "The difference between the two would be that my version uses linear interpolation into a very large table to obtain the filter coefficients while yours are more exact. However mine provides a *measured* SNR of at least 97dB." This second paragraph is considerably flawed and reveals a serious misconception on your part. Although the *starting point for the derivation* of both methods is the same, the method you are using as it is actually implemented is a very localized method in which only few samples are used to construct the new values. This is due to the *severe* truncation of the series. The horrible effects of this severe truncation are mitigated through the application of a Kaiser window which effectively localizes the estimation even further as it improves the result substantially. The method I'm using remains a very much more global method in which each new value is constructed from hundreds of thousands to millions of samples. Given that audio I process taper off to zero at the beginning and end --- in addition to being band-limited and effectively lowpass filtered --- I could have written a global method wherein each sample is the result of calculations involving ALL other samples rather than one which contains windows with hundreds of thousands to millions of samples. This is a far cry from what you are doing. This is all BEFORE the linear interpolation step which you claim is the only difference between our methods, a step which is totally unnecessary by the way for most fixed-sample-rate conversions (for example: unnecessary for 96,000 to 44,100, for 48,000 to 44,100, and for 44,100 to either of the others) and further degrades the sample rate conversion unnecessarily for the most common use. (This was done by Smith to permit variable-sample-rate conversions, a useful goal to say the least.) Now as I've already said, the sinc-based sample-rate converter you've constructed from Smith's work seems to work well in the sample I've listened to. But knowing what I know about sinc-based methods based on my own implementations, Smith's published work, and the lack of necessity for such a method for fixed-rate conversions, not to mention the fact that linear interpolation is being used where it really isn't necessary, leads me to reject libsamplerate and anything related to it unless it's forced on me by someone else via a dependency. I rarely do variable-rate conversions, so I have very little need for sinc- based sample-rate converters. ------------------------- For "ordinary" users: For those of you who have read this far --- hopefully not many: PLEASE don't be alarmed. As I have repeatedly said, Erik's implementation of Smith's work seems to work well. The inaccuracies in that method for fixed rate conversions, including the additional inaccuracy of the unnecessary linear interpolation, seem to be virtually inaudible. The main advantage is that a single method can be used for both fixed- and variable-rate conversions, and this is indeed a *considerable* advantage for a lib-based implementation. We are all indebted to Erik for creating libsamplerate, and this includes me. ------------------------- For developers: Developers, however, should at least be aware of what is going on there. I would advise anyone who has a *critical* dependence on sample-rate conversions to carefully read Smith's notes and to make sure that they understand what is going on. They should also experiment with Smith's technique, including implentation of different windows to see how bad it can be if things go wrong. Erik's "measurements" that I've seen so far aren't very useful for these worst-case situations. Smith may have had something more useful such as a bound of some sort, but frankly I don't recall at this moment and I'm not motivated to check it out at this time (sorry!). I have too much to do following this trip, and this post has taken all my spare time. Sorry for the length, but I wanted to clear up some misconceptions about what I've posted as well as raise a flag (without causing some sort of fiasco) for those who may not have had time to study sinc-based methods. Regards to all, Dave.

21 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-user