Linux-audio-dev December 2003

linux-audio-dev@lists.linuxaudio.org

67 participants
59 discussions

[linux-audio-dev] CD fast forward behaviour

by Paul Davis

does anyone know what a h/w CD player actually does when in fast forward mode? does it skip sectors? how many? etc. thanks.

20 years, 4 months

[linux-audio-dev] Re: [linux-audio-user] Re: Firewire, what's the story?

by Robert Jonsson

Hi, tisdagen den 09 december 2003 12.22 skrev Steve Harris: > On Tue, Dec 09, 2003 at 09:25:42AM +0100, Clemens Ladisch wrote: > > > > I seem to recall that it does, but that the packet size is smaller, > > > > making the latency problem easier to deal with. > > > > > > Isoch - 1394 has a timer operating on the bus. This timer happens > > > (roughly) every 125uS. > > > > USB isochronous transfers happen once per millisecond. > > OK, so its the difference between 44 or 45 samples per packet at 44.1kHz > (USB) and 5 or 6 (1394). > > So, a plausible jack period of 64 samples will be 11 or 12 1395 packets, > but always 125uS of jitter of course, (10 or 11 packets at 48k). > > I dont really have any idea how bad that is, its 8% of the availble time > slot for processing the 64 samples. > > You could lessen the effect of the jitter by having triple-buffering in > software, as in a 3x64 PCI soundcard - I dont know wether thats better > than just going to 128 samples or not. > > FWIW, for my needs I rarely go below 256 samples/period anyway, even > though my setup is capable of it, but I understand there are people who > really need very low latency. > > At 256 samples/period the jitter is only 2.1% of the time slice, which is > unlilkly to matter - cache temperature and so on has a far greater effect > than that. Though it is interesting debating the technical merits of firewire, for me, atleast, it would be far more interesting to get it actually working. I'm _very_ interested in utilizing these hardwares. I googled a little last night, some people we all know popped up here and there (Hi Steve, Mark and Bob). There was a LAD message from 2001, someone who had been in contact with Yamaha and it seemed they(Yamaha) where working towards making mLan a part of the A&M standard (I think I got that right...not sure)... now... I'm not entirely sure what this means. It seemed as the A&M standards also cost a lot of money? Do we have enough information to implement mLan support? As I understand it, Bob Ham had/is working on implementing 61883 support for Jack, which seems like it's needed for mLan, a layer below it perhaps? How far has this come, is there something one can test somehow, what hardware do one need? Regards, Robert ps. I'm cc:ing LAD as I'd like to move the discussion there. Remove LAU if you respond to this. ds.

20 years, 4 months

[linux-audio-dev] Re: [linux-audio-user] Timidity

by holborn

On Martes, 09 de Diciembre de 2003 10:57, Gerrit Niestijl wrote: > Hi, > > When i use timidity in alsa seq mode with a sequencer like muse or > seq24, the timing is not very good. If i use fluidsynth the > timing is much better. I would like to use timidity though, because > of its support for the Midi Tuning Standard. > > Are others seeing this too? Are there any options or > other ways to improve the timing for timidity? try to start timidity with: -B2,8 Josep

20 years, 4 months

[linux-audio-dev] New Linux Audio Column in Linux Journal

by Joern Nettingsmeier

hello linux audio enthusiasts! reading lwn.net this morning i found that the linux journal has a new linux audio column in their online edition, written by dave phillips. the current issue is at http://www.linuxjournal.com//article.php?sid=7283 . the content of this first issue will not be news to you, since it's basically a plug for the world's finest linux audio mailing lists, which you already seem to know about :) still, it's an interesting read, and it has had an effect already: about 30 new subscriptions (in addition to the usual continous growth) since wednesday... (see http://www.linuxdj.com/audio/lad/subscribe.php3 .) to all new readers: welcome aboard! best, jörn -- To someone whose only tool is a hammer, each problem looks like a nail. - Edsger W. Dijkstra, EWD838 Jörn Nettingsmeier Kurfürstenstr 49, 45138 Essen, Germany http://spunk.dnsalias.org (my server) http://www.linuxaudiodev.org (Linux Audio Developers)

20 years, 4 months

[linux-audio-dev] [ANN] AlsaPlayer 0.99.76

by Andy Lo A Foe

Hi, AlsaPlayer 0.99.76 is out. This is a bugfix release. Things should run much better on NPTL enabled systems (e.g. latest Debian and Redhat). The playlist doesn't loop by default anymore. There were also some cleanups in the core. The next few releases will focus on bringing in a new GTK2 based interface and improving support for JACK. Download: ftp://ftp.alsa-project.org/pub/people/andy/alsaplayer-0.99.76.tar.bz2 http://www.alsaplayer.org/alsaplayer-0.99.76.tar.bz2 Homepage: http://www.alsaplayer.org Please report bugs, etc. to the alsaplayer-devel mailing list. Enjoy! Andy @ alsaplayer.org

20 years, 4 months

Re: [linux-audio-dev] virtual vocalist - I think we could

by Juhana Sadeharju

>From: David Olofson <david(a)olofson.net> > >BTW, where did the Zero-G site go? Seems dead, and I can't find any >demos elsewhere... Here are urls for demos: http://www.vocaloid.com/demos/MicroOrche_128.mp3 http://www.yamaha.co.jp/product/vocaloid/demos/Vocaloid_for_you_128.mp3 http://www.yamaha.co.jp/product/vocaloid/demos/kimi_no_uwasa_128.mp3 http://www.yamaha.co.jp/product/vocaloid/demos/mahou_no_kurukuru_128.mp3 http://www.yamaha.co.jp/product/vocaloid/demos/partyline_128.mp3 http://www.yamaha.co.jp/product/vocaloid/demos/thepoint_128.mp3 http://www.yamaha.co.jp/product/vocaloid/demos/totoumi_koiuta_128.mp3 http://www.yamaha.co.jp/product/vocaloid/demos/yukigeshiki_128.mp3 There are also the following files from zero-g site but have no urls now: LOLA_Demo_1_Little_Bird.mp3 LOLA_Demo_2_Bach_Vowels.mp3 Some of the demos seems to have also a human singer. The one which sounds worse is the vocaloid. Regards, Juhana

20 years, 4 months

[linux-audio-dev] Capabilities patches for a 2.4 kernel.

by Luke Yelavich

Hi all I haven't really been following the discussion about the capabilities patches etc, so bare with me if I have missed anything. I am currently preparing an updated kernel, and am wondering whether any of the proposed patches for a 2.4 kernel are stable enough to be usable. If so, where can I obtain the patches? Thanks Luke -- Luke Yelavich AudioSlack Founder and head package maintainer Audio software packaged for the Slackware Linux Distribution http://www.audioslack.com luke(a)audioslack.com

20 years, 4 months

[linux-audio-dev] Ecasound 2.3.2 released

by Kai Vehmanen

1. A short summary of changes Support has been added for libsndfile. This allows to access a number of new audio file formats such as W64, PVF and VOC files. Integration with libaudiofile and MikMod has also been improved. Bugs in the native Python ECI implementation have been fixed. Rubyecasound, a Ruby ECI implementation, has been added to the package. A serious memory-leak in list handling functions of the C ECI implementation was fixed. This bugfix also affects C++, Perl and PHP ECI implementations. Compiling Ecamegapedal works again as the header files missing from the previous 2.3.1 release are now again included in the dist-package. Many minor bugs have been fixed. --- 2. What is Ecasound? Ecasound is a software package designed for multitrack audio processing. It can be used for simple tasks like audio playback, recording and format conversions, as well as for multitrack effect processing, mixing, recording and signal recycling. Ecasound supports a wide range of audio inputs, outputs and effect algorithms. Effects and audio objects can be combined in various ways, and their parameters can be controlled by operator objects like oscillators and MIDI-CCs. A versatile console mode user-interface is included in the package. Ecasound is licensed under the GPL. The Ecasound Control Interface (ECI) is licensed under the LGPL. --- 3. Changes since last release * Rubyecasound, a Ruby ECI implementation, has been added to the package. Developer documentation can be found at <http://eca.cx/eci>. Rubyecasound was developed by Jan Weil. * Some files were missing from the previous 2.3.1 release dist-package. This caused the "make check" test procedure to fail, and also prevented from compiling Ecamegapedal against 2.3.1. In 2.3.2 the missing files are once again included in the dist-package. * Libsndfile support has been added to Ecasound (development item 'edi-33'). Support for libaudiofile has also been improved in this release. The user can now compile in support for both libraries at the same time. It is possible to use command-line options to select which library to use for a given file. Similar improvements have been made to the MikMod support. See the ecasound(1) man page for more details. * Some bugs in libsamplerate integration have been fixed. Upgrading to libsamplerate version 0.0.15 or newer is recommended. This release contains a few important fixes that affect Ecasound. A few examples of resampling with Ecasound have been added to the docs: <http://www.wakkanet.fi/~kaiv/ecasound/Documentation/examples.html>. * A severe memory-leak bug was found and fixed in the C ECI implementation. This bug affects applications that heavily use EIAM commands that return lists of strings. The C ECI is used by C++, Perl, PHP and Python ECI implementations. * Bugs in the native Python ECI implementation have been fixed. The C-based Python ECI implementation is still selected as the default, but you can override this with the '--enable-pyecasound=python' option to configure. Note, 'native' here means that ECI API is implemented without linking to any Ecasound libraries. Instead the ECI implementation forks 'ecasound' binary on the background and communicates with it using pipes. This allows for clear decoupling between ECI apps and specific Ecasound version. More information about ECI can be found at <http://www.eca.cx/eci>. Full list of changes is available at <http://www.wakkanet.fi/~kaiv/ecasound/history.html>. --- 4. Interface and configuration file changes None. --- 5. Contributors Patches - Accepted code, documentation and build system changes Jan Weil (2) -- rubyecasound ECI implementation, new docs Mark de Wever (1) -- typo in libecasoundc-config usage Kai Vehmanen (various) Bug Hunting - Reports that led to bugfixes (items closed) Fernando Pablo Lopez-Lezcano (1) -- preset.h not installed Jan Weil (1) -- the ecacontrol.py bug --- 6. Links and files Web sites: http://www.eca.cx http://www.eca.cx/ecasound http://www.eca.cx/eci Source packages: http://ecasound.seul.org/download http://ecasound.seul.org/download/ecasound-2.3.2.tar.gz Distributions with maintained Ecasound support: Agnula - http://www.agnula.org AltLinux - http://www.altlinux.com Debian - http://www.debian.org FreeBSD - http://www.freebsd.org/ports/audio.html Gentoo Linux - http://www.gentoo.org Mandrake - http://www.mandrake.org PLD Linux - http://www.pld.org.pl SuSE Linux - http://www.suse.de/en Contrib Packages and Add-On Distributions: AudioSlack for Slackware - http://www.audioslack.com PlanetCCRMA for RedHat/Fedora - http://www-ccrma.stanford.edu/planetccrma/software Thac's RPMs for Mandrake - http://rpm.nyvalls.se Apps.kde.com packages for Mandrake/Redhat/SuSE - http://apps.kde.com/rf/2/info/id/2146 Note! Distributors do not necessarily provide packages for the very latest Ecasound version. -- http://www.eca.cx Audio software for Linux!

20 years, 4 months

[linux-audio-dev] Jack-0.91.1 release

by Taybin Rutkin

Jack 0.91.1 has been released. Changes: New iec61883 driver. Very experimental; this is just to get it out there. 61883 is the standard for audio+midi over firewire. Run configure with --enable-iec61883 to compile it. It requires libraw1394. Added callback for notifying clients when entering freewheeling mode and leaving it: int jack_set_freewheel_callback (jack_client_t *client, JackFreewheelCallback freewheel_callback, void *arg); Bugs fixed. Compiler warnings removed. Taybin Rutkin

20 years, 4 months

[linux-audio-dev] Linux Security Module for realtime audio

by Jack O'Quin

I am cross-posting this to LAD, hoping to get some useful feedback. Paul Davis <paul(a)linuxaudiosystems.com> writes: > about that patch ... torben hohn wrote, some time ago on LAD (see his > comment at the end). does anyone have time to check on this? > > Have a look at linux security modules. In the 2.5 kernel the > > patch you propose is not a patch, it is a kernel module. I spent some time last night looking at... (*) linux-2.6.0-test9 kernel sources (from Debian) (*) SELinux 2.60-test6 sources from NSA, http://www.nsa.gov/selinux (*) the Linux Security Modules web site http://lsm.immunix.org As always with the web it's hard to tell the real stuff from the vaporware. But, this stuff looks real to me. :-) SELinux (Security-Enhanced Linux) is NSA's research project for implementing DoD Orange-book security features as a pluggable kernel module. Almost all of the SELinux modularization changes are present in linux-2.6.0-test9. Their entire compressed patch for the 2.6.0-test6 kernel was only 1889 bytes containing 189 lines of context diffs. By comparison, they also distribute an SELinux patch for 2.4.21, which is 209KB (compressed) containing almost 36,000 lines of context diffs. Internally, the 2.6 kernel exclusively uses `if(capable(CAP_foo))' tests, AFAICT. That was already (mostly) true of 2.4. In 2.6, there are pluggable security modules to control the semantics of these tests. The vanilla test9 kernel includes a small example security module, `security/root_plug.c', which tests for the presence of a specific USB device at exec time, only allowing setuid if it is present. It is only 143 lines long. Domain and Type Enforcement (DTE) is another project using a loadable security module. It seems to be aimed at Mandatory Access Controls for partitioning the file access capabilities of root processes. The idea is to run root daemons in a "Domain" that lacks the ability to modify important system files like /bin/login and /etc/passwd, frequent targets for evil crackers exploiting buffer overflows in their victim daemons. ;-) This leads me to believe that 2.6 *does* permit one to write a kernel security module for selectively granting realtime permissions to certain processes. The mechanisms provided are far more powerful than necessary for that simple application. I don't know exactly what realtime security policy should be implemented and how the underlying mechanisms ought to be used, though I have some ideas. But, the first step is to figure out if someone is already working on this. My late-night googling didn't discover any existing project, but surely someone is doing it by now. If not, I think we should consider building and distributing one as part of JACK. Comments? -- joq

20 years, 4 months

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 December 2003