Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7513 discussions

[linux-audio-dev] [OT] ALSA Modular can't open ALSA device

by Artemiy Pavlov

Hello all! Please excuse me for a little off-topic post. I've just upgraded my Mandriva distro from 2005 to 2006, and now AMS won't start: [artemio@localhost ams-1.8.7]$ ams QMultiInputContext::changeInputMethod(): index=0, slave=xim LADSPA_PATH: /usr/lib/ladspa/ loadPath: /home/artemio/audio/patches/AMS/, savePath: /home/artemio/audio/patches/AMS/ Alsa_driver: detected more than 1024 playback channnels, reset to 2. ALSA lib pcm_mmap.c:368:(snd_pcm_mmap) mmap failed: Invalid argument Alsa_driver: can't set playback hardware parameters. Can't connect to ALSA What can this mean? Other audio apps making use of ALSA work just fine (Hydrogen, ZynAddSubFx, etc.). Thanks for any help, Artemiy.

19 years, 10 months

[linux-audio-dev] Re: Mixer controls

by Juhana Sadeharju

>From: James Courtier-Dutton <James(a)superbug.co.uk> > >It was just an example. The actual range depends on the sound card >hardware, but the typical limit is something like -60 dB or -80 dB. Do you process each channel with audio software prior mixing? If yes, then I would suggest to fix the hardware levels to the optimum level, and use gains only in software. As FA wrote, soundcards most likely do not have click-free mutes and smooth gains. When the hardware is fixed, you may do faded mutes in software with good quality. Fixing the hardware input and output levels makes sense to me. The input devices all have fixed SNR -- it does not help to crank up the soundcard input level as it brings the noise up. The output would be fixed for the same reasons. Also, fixing the output prevents you accidentally damage the speakers and your ears. When you crank up the gain in software, you may have a software limiter prior the monitor outputs. Once I watched when a friend mastered CDs. The fades were auditioned by cranking up the level on the mixer desk. A couple of times happened that the level was not set back to normal position when needed. :-| By fixing the hardware (including external mixer desk) in the audio path, you may have full control with the software. Soundcards are not optimal for listening fades. Only software gain allows one to audition the fades. With hardware gain the sound can be muddy, but most likely your card cannot make +64 dB gains needed in listening the fades. Cards equipped with an user-programmable dsp chip allows one to move the code from the software to the firmware. I'm in understanding that in SB Live all hardware gains are actually software gains. I.e., they have fixed the hardware. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software

19 years, 10 months

[linux-audio-dev] Mixer controls

by James Courtier-Dutton

Hi, I am an ALSA developer. I was hoping that someone on this list would have experience with professional mixing desks. I would like to duplicate the behavior of professional mixing desks in the alsa mixer controls. I am only interested in gain control at this point. There are effectively two separate but linked controls for each gain control. a) Mute control b) Gain control in dB. If I have a gain control that starts at 0 dB, with each step down by 1 dB until -40dB. With DSPs, it is very easy to add the next step down as being the mute level. E.g. Sample * gain_multiplier where for the mute level, gain_multiplier = 0.0, thus resulting is a zero sample output. My question is really what should I do when the gain_multiplier is 0.0 Do I: a) Limit the range of the gain control to 0dB to -40 dB and have a separate Mute control. b) When the gain control has a gain_multiplier of 0.0, automatically activate the Mute control. c) Some other method. Thank you James

19 years, 10 months

[linux-audio-dev] Juno6 GPL sources

by Artemiy Pavlov

Dear friends, I have managed to contact the guy (Sebastian Gottschall, brainslayer/at/braincontrol/dot/org) who is converting the UltraMaster Juno6 synth to windows VST format and I got the original sources from them. According to his saying, the original authors allowed him to publish the sources as GPL so there should be no worrying even though each and every file in there contains the old restricting license notice. You will find the sources at my web site: http://artemio.net/projects/juno6/download/source/juno-1.0.1.tar.bz2 I have made an attempt to build Juno6, but AFAIK it is based on glibc 1.x and many C expressions they have are obsolete. But I believe that with some little tweaks the code will compile, though I myself won't be able to help. What I want to ask, is someone interested in resurrecting this nice synthie? First step would be to make it compile with the current feature set. Then see if it's possible to add ALSA MIDI and audio support, and so on (maybe add DSSI too, etc.). I would assist in providing a dedicated web site and hosting for it, no probs. Again, it's a very nice synth with fat and warm sound, I think it really is worth the work. With best wishes, Artemiy.

19 years, 10 months

[linux-audio-dev] Re: [linux-audio-user] jack and setuid

by Jonathan Woithe

Florian Schmidt wrote: > > since i'm using 2.6.14 , you mean set_rtlimits from > > http://www.physics.adelaide.edu.au/~jwoithe/set_rtlimits-1.1.0.tgz ? > > > > but if i run jack as a user, there are no capture ports, and i have tons of > > xruns. > > Just for completeness sake: You can use the realtime lsm for 2.6.13 and > above, too. I would even recommend it, since it's much less of a hassle > to setup (rt_limits being the "correct" solution or not). I'm a bit puzzled by this statement. lsm requires you get the patch, apply it to your kernel, configure and compile your kernel, install and boot the new kernel and then you can start configuring userspace to take advantage of it. In contrast, using the rtlimits approach can be as simple as grabbing set_rtlimits and compiling it (assuming one has a kernel >= 2.6.13 installed of course). Configuring userspace is via a single simple text file (documented in the source distribution). Using it then boils down to doing things like set_rtlimits -r /usr/local/bin/jackd ... set_rtlimits -r /usr/local/bin/ardour etc when starting applications which need it. Aliases can even be used to hide the set_rtlimits bit if desired. To me this seems a *lot* easier than messing around with patched kernels. It *is* true that (on systems which use PAM) PAM can be patched to provide access to the rtlimits functionality in a transparent way. I will admit that doing things this way is complex and a hassle. I wrote set_rtlimits for two reasons: 1) give myself access to the rtlimits functionality - my system doesn't run PAM, so the PAM patches aren't useful to me personally. 2) provide a much simpler way to get access to the rtlimits functionality in this interim period until PAM (or login in the case of systems not using PAM) support rtlimits out the box. set_rtlimits can also control access to the rtlimit resource on a per-program basis. A patched login wouldn't be able to do this; PAM may or may not - I don't know enough about it to comment. Of course everyone is free to choose the solution which best suits them; if people prefer lsm that's fine by me. As a side comment, I'm currently finalising a new version of set_rtlimits. I've generalised it so it can set other resource limits too - locked-in-memory size for example - since this can also be useful to control on a per-program basis. Consequently its name will change to set_rlimits but the version number will be sequential. Invocation has also been made easier (absolute paths will no longer need to be specified - they will be pulled from the configuration file). I expect to have time to finalise it in the next couple of weeks. Best regards jonathan

19 years, 10 months

[linux-audio-dev] the big jack bug... > crappy audio on XRUNS

by federico

it happens randomly, while I play a soft synth, that jack XRUNs once, and the audio become crappy, noisy, like a kinda of digital effect....bit crusher? then all synthesizers (all audio apps) sound the same sh*t... i tried recording with ardour the output, and the output is clean, so I guess is a problem of sync or something that has to do with the hardware (soundcard). in order to record this noise, i had to connect the soundcard output in its input and record it via analog in: http://xaero.ath.cx/jackbug_stereo.wav.bz2 (it is a stereo file, with the clean track panned on the left, and the dirty one on the right). i hope it could be useful to debug the problem... what other information I can provide useful for debug? note that this happens with many version of alsa (1.0.9b, 1.0.10rc2, 1.0.7 or less) and with many kernels (gentoo-sources (slightly patched for speed improvement), ck-sources, ck-sources+realtime-lsm) i hope to solve this problem, since my audio desktop is unusable as si, since audio crasher after playng for just 5 minutes :(

19 years, 10 months

[linux-audio-dev] Re: the big jack bug... > crappy audio on XRUNS

by Luis Garrido

Hi! I had a similar problem in my laptop when using a USB soundcard (Edirol UA-25). For me it was not necessarily associated with xruns. Since ardour doesn't record the noise, I would say that the problem is not in jack, but in the alsa driver. It sounded also more like a distortion than noise, since when the output levels were low the effect was less noticeable. I found empirically that harddisk writing operations like saving a file in an application would sometimes make the distortion stop, I'll be damned if I know why (interrupts?). Anyway, setting my USB unit to work at 48 kHz made this problem practically disappear. HTH, Luis > it happens randomly, while I play a soft synth, that jack XRUNs once, > and the audio become crappy, noisy, like a kinda of digital > effect....bit crusher? > > then all synthesizers (all audio apps) sound the same sh*t... > i tried recording with ardour the output, and the output is clean, so I > guess is a problem of sync or something that has to do with the hardware > (soundcard). > > in order to record this noise, i had to connect the soundcard output in > its input and record it via analog in: > http://xaero.ath.cx/jackbug_stereo.wav.bz2 (it is a stereo file, with > the clean track panned on the left, and the dirty one on the right). > > i hope it could be useful to debug the problem... > what other information I can provide useful for debug? > note that this happens with many version of alsa (1.0.9b, 1.0.10rc2, > 1.0.7 or less) and with many kernels (gentoo-sources (slightly patched > for speed improvement), ck-sources, ck-sources+realtime-lsm) > > i hope to solve this problem, since my audio desktop is unusable as si, > since audio crasher after playng for just 5 minutes :( > >

19 years, 10 months

[linux-audio-dev] Status of mLAN or similar?

by Thomas Vecchione

I am wondering what the status of the mLAN or something similar is in linux? I have been able to find some mention of talking with Yamaha about it, but past that I cant seem to find anything on it. I am looking for a solution to allow me to connect and stream audio in realtime over firewire to a Mac Mini to run some VSTs on until VST support in Linux is worked out completly. Thanks. Seablade

19 years, 10 months

[linux-audio-dev] Re: Radio receiver.

by Juhana Sadeharju

Thanks for the tip on "diversity reception". Yes, I got the idea from astronomer's systems. I use the term "invented" the same way as patenteers: due lack of extensive literary search, I know at most that the thing is new to me. Though, I have never seen such a system used in consumer radios. I'm not sure if it have been used in DX'ing radios either. My test plan was to record the same music station at two cities (apart 200km). Then timescale and align the digitized (1 or 2 hours) recordings manually. And then do the thing. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software

19 years, 10 months

[linux-audio-dev] [ANN] rt_watchdog

by Florian Schmidt

Hi, here http://affenbande.org/~tapas/rt_watchdog.tgz you find a small program which acts as a watchdog daemon that kills runaway SCHED_FIFO tasks. It does so by setting up two threads: - one high priority (99) consumer that runs every 3 seconds - one low priority (1) producer that runs every second the producer fills a ringbuffer and the consumer drains it. When the ringbuffer runs empty a shell script will be run (via the system() function) that tries to change the scheduling policy of all threads in the system from SCHED_FIFO to SCHED_OTHER. the offending task may naturally not run at prio 99, otherwise the watchdog would never get to run. Here's a potential problem: The shell script potentially changes its own scheduling policy to SCHED_OTHER prior to chnaging the offending runaway task. Ugh! Any hint? Also all IRQ handler threads also have their policy changed. Dunno whether that's good or not. For reference i pasted the script and the c file here: unfifo_stuff.sh (the two arguments are the two thread id's of the rt_watchdog threads, as these are not supposed to have their policy changed). There's also a small test program in the tarball (compiles to test_rt) that wastes cycles SCHED_FIFO (locking the system) but exits eventually, so it's quite safe to test the watchdog with it. Maybe someone else find's it useful. Recommendations, tips, critique are all welcome.. unfifo_stuff.sh #!/bin/bash for i in $( ps -eL -o pid ); do if [ "$i" != "$1" -a "$i" != "$2" ] then chrt -o -p 0 $i fi done rt_watchdog.c: #include <pthread.h> #include <stdlib.h> #include <stdio.h> #include <unistd.h> #include <syslog.h> #include <signal.h> #include <sys/mman.h> #include <sys/stat.h> #include <sys/types.h> #include <linux/unistd.h> #include <errno.h> _syscall0(pid_t,gettid) #include "ringbuffer.h" /* how long to sleep between checks in the high prio thread */ #define SLEEPSECS 3 /* how long to sleep between writing "alive" messages to the ringbuffer from the low prio thread */ #define LP_SLEEPSECS 1 /* the priority of the high prio thread */ #define PRIO 99 /* the priority of the low prio thread */ #define LP_PRIO 1 /* the ringbuffer used to transfer "alive" messages from low prio producer to high prio consumer */ jack_ringbuffer_t *rb; pthread_t low_prio_thread; /* the thread id's for the low prio and high prio threads. these get passed to the unfifo_stuff.sh script to make sure the watchdog doesn't repolicy itself to SCHED_OTHER */ pid_t lp_tid; pid_t hp_tid; void signalled(int signal) { } volatile int thread_finish; /* this is the low prio thread. it simply writes to the ringbuffer to signal that it got to run, meaning it is still alive */ void *lp_thread_func(void *arg) { char data; struct timespec tv; lp_tid = gettid(); /* syslog(LOG_INFO, "lp tid: %i", gettid()); */ data = 0 ; while(!thread_finish) { /* we simply write stuff to the ringbuffer and go back to sleeping we can ignore the return value, cause, when it's full, it's ok the data doesn;t have any meaning. it just needs to be there running full shouldn't happen anyways */ jack_ringbuffer_write(rb, &data, sizeof(data)); /* then sleep a bit. but less than the watchdog high prio thread */ tv.tv_sec = LP_SLEEPSECS; tv.tv_nsec = 0; // sleep(LP_SLEEPSECS); nanosleep(&tv, NULL); } return 0; } int main() { pid_t pid, sid; int done; struct sched_param params; char data; int err; int consumed; int count; struct timespec tv; char unfifo_cmd[1000]; /* Fork off the parent process */ pid = fork(); if (pid < 0) { exit(EXIT_FAILURE); } /* If we got a good PID, then we can exit the parent process. */ if (pid > 0) { exit(EXIT_SUCCESS); } /* Change the file mode mask */ umask(0); /* Open any logs here */ openlog("rt_watchdog", 0, LOG_DAEMON); syslog(LOG_INFO, "started"); /* Create a new SID for the child process */ sid = setsid(); if (sid < 0) { /* Log any failure here */ syslog(LOG_INFO, "setsid failed. exiting"); exit(EXIT_FAILURE); } /* Change the current working directory */ if ((chdir("/")) < 0) { /* Log any failure here */ syslog(LOG_INFO, "chdir failed. exiting"); exit(EXIT_FAILURE); } /* Close out the standard file descriptors */ close(STDIN_FILENO); close(STDOUT_FILENO); close(STDERR_FILENO); // syslog(LOG_INFO, "closed fd's"); /* syslog(LOG_INFO, "hp tid: %i", gettid()); */ hp_tid = gettid(); /* not really nessecary, but wtf */ mlockall(MCL_FUTURE); thread_finish = 0; done = 0; /* get ourself SCHED_FIFO with prio PRIO */ params.sched_priority = PRIO; if (pthread_setschedparam(pthread_self(), SCHED_FIFO, &params)) { syslog(LOG_INFO, "couldn't set realtime prio for main thread.. exiting.."); exit(EXIT_FAILURE); } // syslog(LOG_INFO, "prio set"); /* create a ringbuffer for the low prio thread to signal it's alive */ rb = jack_ringbuffer_create(1024); // syslog(LOG_INFO, "ringbuffer created"); /* create low prio thread */ err = pthread_create(&low_prio_thread, 0, lp_thread_func, 0); if(err) { syslog(LOG_INFO, "couldn't create low prio thread, exiting.."); exit(EXIT_FAILURE); } /* dirty. we really need to wait for the lp thread to have written the lp_tid. (condition variable?) */ sleep(1); // syslog(LOG_INFO, "created low prio thread"); /* make the low prio thread sched_fifo */ params.sched_priority = LP_PRIO; if (pthread_setschedparam(low_prio_thread, SCHED_FIFO, &params)) { syslog(LOG_INFO, "couldn't set realtime prio for lower prio thread.. exiting.."); thread_finish = 1; pthread_join(low_prio_thread, NULL); exit(EXIT_FAILURE); } /* this is the main loop. we somply check whether the low prio thread got to run at all by looking into the ringbuffer. If it's empty, the low prio thread is kinda dead */ count = 0; while(!done) { tv.tv_sec = SLEEPSECS; tv.tv_nsec = 0; nanosleep(&tv, NULL); /* sleep(SLEEPSECS); */ count++; /* syslog(LOG_INFO, "count %i", count); */ /* see if our little brother got to run */ if (jack_ringbuffer_read_space(rb) == 0) { /* oh oh, it didn't */ syslog(LOG_INFO, "low prio thread seems to be starved, taking measures..."); /* we pass our own TID's to the script, so we are excluded from the scheduling policy change */ sprintf(unfifo_cmd, "unfifo_stuff.sh %i %i", lp_tid, hp_tid); syslog(LOG_INFO, "unfifo command:"); syslog(LOG_INFO, unfifo_cmd); if (system(unfifo_cmd) == -1) { syslog(LOG_INFO, "unfifo command failed"); } } else { /* consume stuff from ringbuffer */ consumed = 0; while (jack_ringbuffer_read_space(rb)) { consumed++; jack_ringbuffer_read(rb, &data, 1); } /* syslog(LOG_INFO, "lp alive: %i", consumed); */ } } thread_finish = 1; pthread_join(low_prio_thread, NULL); syslog(LOG_INFO, "exiting"); exit(EXIT_SUCCESS); } test.c: #include <pthread.h> #include <stdlib.h> #include <sys/time.h> #include <time.h> int main() { struct sched_param params; int done = 0; struct timeval tv; time_t startsec; unsigned long int loops; int outer_loops; params.sched_priority = 80; pthread_setschedparam(pthread_self(), SCHED_FIFO, &params); gettimeofday(&tv,0); startsec = tv.tv_sec; #if 0 while(!done) { gettimeofday(&tv, 0); if(tv.tv_sec - startsec > 10) done = 1; } #endif for (outer_loops = 0; outer_loops < 4; ++outer_loops) { for (loops = 0; loops < 1000000000; loops++) {done += 1;} } exit (EXIT_SUCCESS); } -- Palimm Palimm! http://tapas.affenbande.org

19 years, 10 months

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-dev