Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

by Aaron

Hi all, Denemo is really lacking alsa support. Unfortunatly Denemo has only one coder who is working a full time job. Is there a kind soul out there who could help implement ALSA support for Denemo. And if you live nearby I would gladly buy you a beer of your choice :) thats if you drink beer... Thanks Aaron

19 years, 11 months

[linux-audio-dev] the Linux-Powered Korg OASYS

by Jan Weil

<http://digitalmedia.oreilly.com/2005/11/09/inside-the-korg-oasys.html> Cheers Jan

19 years, 11 months

[linux-audio-dev] LDAS (Low Delay Audio Streamer) 0.1.0

by asbjs＠stud.ntnu.no

LDAS (Low Delay Audio Streamer) is software for full-duplex low-latency transmission of audio over IP. This is the first public release. At this point, the basic functionality is present -- LDAS is capable of transmitting full duplex two-channel audio between two computers. This has been tested using the ldas_mate binary running on two computers equipped with SoundBlaster Live sound cards. (Note however that the software is still in an early state. Features are lacking, and the code is somewhat fragile.) * Download: http://www.q2s.ntnu.no/~asbjs/ldas/ldas-0.1.0.tar * Web page: http://www.q2s.ntnu.no/~asbjs/ldas/ldas.html * Mailing list: https://pat.q2s.ntnu.no/mailman/listinfo/ldas-dev * Q2S web page: http://www.q2s.ntnu.no/ LDAS is released under the GNU GPL. It comes with no warranty. Many thanks to Lee Revell, who has taken part in the development of LDAS. His contributions have been very valuable, and a great help in getting this far. LDAS is developed at Centre for Quantifiable Quality of Service in Communication Systems (Q2S), at the Norwegian University of Science and Technology. Asbjørn Sæbø -- Asbjørn Sæbø Post.doc., Centre for Quantifiable Quality of Service in Communication Systems Norwegian University of Science and Technology

19 years, 12 months

[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, 12 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, 12 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, 12 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, 12 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

20 years

[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 :(

20 years

[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 :( > >

20 years

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