Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7536 discussions

[LAD] lwn.net write-up of realtime session @ kernel summit 2009

by Jörn Nettingsmeier

http://lwn.net/SubscriberLink/357800/0fb8fb6f0975403c/ interesting coverage as usual, thanks to lwn for the free-link feature.

16 years, 3 months

Re: [LAD] BFS and lennart's realtimekit idea...

by Kjetil S. Matheussen

J?rn Nettingsmeier: > > this looks like it could provide a simple way of granting fixed-deadline > tasks appropriate cpu time without effectively handing the machine over. > i was quite skeptical of lennart's idea of a userspace daemon to do the > job reliably, but the scheduler should have pretty good leverage on > rogue tasks :) > Why do you need a special scheduling mode? If you run a watchdog in the background, you shouldn't handle the machine over. ***** plug! ***** "das_watchdog" should be a properly made watchdog. It has saved me numerous times, and works gently by temporarily turning off realtime priority for all processes if something happens. http://archive.notam02.no/arkiv/src/

16 years, 3 months

Re: [LAD] BFS and lennart's realtimekit idea...

by Jörn Nettingsmeier

[paul, i assume this was meant for the list?] Paul Davis wrote: > 2009/10/22 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>: >> hi everyone! > > this: > >> A feature of BFS is that it detects when an application tries to obtain a >> realtime policy (SCHED_RR or SCHED_FIFO) and the caller does not have the >> appropriate privileges to use those policies. When it detects this, it will >> give the task SCHED_ISO policy instead. Thus it is transparent to the user. >> Because some applications constantly set their policy as well as their nice >> level, there is potential for them to undo the override specified by the user >> on the command line of setting the policy to SCHED_ISO. To counter this, once >> a task has been set to SCHED_ISO policy, it needs superuser privileges to set >> it back to SCHED_NORMAL. > > doesn't sound like linux or linus style of policy to me. i'll be > interested to see what happens. yeah, that's not exactly a touch of genius, but con's user base are, well, users. making stuff out of the box is how he attracts testers. in the long run, this should be a limits.conf thing, but in his position , "wait for your distro to make this work" is a non-starter. if bfs ever makes it into mainline, this behaviour will surely be shot down. but the rest sounds interesting. i wonder how the new deadline scheduler will compare.

16 years, 3 months

[LAD] BFS and lennart's realtimekit idea...

by Jörn Nettingsmeier

hi everyone! i just came across con kolivas' announcement of the latest release of the brain fuck scheduler, http://lwn.net/Articles/357451/ . in it, he explains the idea behind isochronous scheduling (which lennart brought up when announcing his realtime kit): > Isochronous scheduling. > > Isochronous scheduling is a unique scheduling policy designed to provide > near-real-time performance to unprivileged (ie non-root) users without the > ability to starve the machine indefinitely. Isochronous tasks (which means > "same time") are set using, for example, the schedtool application like so: > > schedtool -I -e amarok > > This will start the audio application "amarok" as SCHED_ISO. How SCHED_ISO works > is that it has a priority level between true realtime tasks and SCHED_NORMAL > which would allow them to preempt all normal tasks, in a SCHED_RR fashion (ie, > if multiple SCHED_ISO tasks are running, they purely round robin at rr_interval > rate). However if ISO tasks run for more than a tunable finite amount of time, > they are then demoted back to SCHED_NORMAL scheduling. This finite amount of > time is the percentage of _total CPU_ available across the machine, configurable > as a percentage in the following "resource handling" tunable (as opposed to a > scheduler tunable): > > /proc/sys/kernel/iso_cpu > > and is set to 70% by default. It is calculated over a rolling 5 second average > Because it is the total CPU available, it means that on a multi CPU machine, it > is possible to have an ISO task running as realtime scheduling indefinitely on > just one CPU, as the other CPUs will be available. Setting this to 100 is the > equivalent of giving all users SCHED_RR access and setting it to 0 removes the > ability to run any pseudo-realtime tasks. > > A feature of BFS is that it detects when an application tries to obtain a > realtime policy (SCHED_RR or SCHED_FIFO) and the caller does not have the > appropriate privileges to use those policies. When it detects this, it will > give the task SCHED_ISO policy instead. Thus it is transparent to the user. > Because some applications constantly set their policy as well as their nice > level, there is potential for them to undo the override specified by the user > on the command line of setting the policy to SCHED_ISO. To counter this, once > a task has been set to SCHED_ISO policy, it needs superuser privileges to set > it back to SCHED_NORMAL. This will ensure the task remains ISO and all child > processes and threads will also inherit the ISO policy. this looks like it could provide a simple way of granting fixed-deadline tasks appropriate cpu time without effectively handing the machine over. i was quite skeptical of lennart's idea of a userspace daemon to do the job reliably, but the scheduler should have pretty good leverage on rogue tasks :) has anyone tried the bfs for audio yet? best, jörn

16 years, 3 months

[LAD] Salon Linux 2010 Paris

by Maurizio De Cecco

Hallo, this message is to inform the community that in the next edition of the the "Salon Linux 2010", in march 2010 in Paris, a french Linux event including a conference cycle, there will be a session around professional music and video creation with free software. You can find the call for contribution at http://www.confsolutionslinuxparis.com/. The call talk about contribution and not paper because actually only a presentation is required, not a paper. We are looking mostly for overviews of availables solutions or in depth presentations of mainstream ''products''. Unfortunately, the communication must be in french :-< ... Feel free to distribute this mail where do you think it may be appropriate, or to contact me to get more details. Maurizio De Cecco -- Music: http://www.myspace.com/mauriziodececco Blog: http://maurizio.dececco.name/ Software: http://www.jmax-phoenix.org/

16 years, 3 months

[LAD] Undeliverable mails for Rui

by Ralf Mardorf

Hi Rui :) after it failed to send the wanted test to you, because of it's length, I'm blocked :D. Sorry LAD list, Rui is waiting for this test and I don't know how to reach him, while I'm blocked. Cheers, Ralf System Administrator wrote: > Your message > > To: Rui Nuno Capela > Cc: qtractor-devel(a)lists.sourceforge.net > Subject: Re: Sound quality of audio recordings at 96 Khz/ 24 Bit > internal Linux - b4: Re: [solved] 'offset/ note length' issue > Sent: Tue, 20 Oct 2009 02:47:02 +0200 > > did not reach the following recipient(s): > > rncbc(a)rncbc.org on Tue, 20 Oct 2009 02:47:26 +0200 > You do not have permission to send to this recipient. For > assistance, contact your system administrator. > <smtp-out02.alice-dsl.net #5.7.1 smtp;554 5.7.1 Service unavailable; > Client host [88.44.60.12] blocked using bl.spamcop.net; Blocked - see > http://www.spamcop.net/bl.shtml?88.44.60.12> > > ------------------------------------------------------------------------ > > Reporting-MTA: dns; HSNMST02V06.hsn.alice-dsl.net > > Final-Recipient: RFC822; rncbc(a)rncbc.org > Action: failed > Status: 5.7.1 > X-Supplementary-Info: <smtp-out02.alice-dsl.net #5.7.1 smtp;554 5.7.1 Service unavailable; Client host [88.44.60.12] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?88.44.60.12> > X-Display-Name: rncbc(a)rncbc.org > > > ------------------------------------------------------------------------ > > Subject: > Re: Sound quality of audio recordings at 96 Khz/ 24 Bit internal Linux > - b4: Re: [solved] 'offset/ note length' issue > From: > "Ralf Mardorf" <ralf.mardorf(a)alice-dsl.net> > Date: > Tue, 20 Oct 2009 02:47:02 +0200 > To: > "Rui Nuno Capela" <rncbc(a)rncbc.org> > > To: > "Rui Nuno Capela" <rncbc(a)rncbc.org> > CC: > <qtractor-devel(a)lists.sourceforge.net> > > > > > Qtractor didn't show the waveform for the brown noise recording > > completely, I don't know the reason why and I never had this bug or > > user error before > > After closing and launching Qtractor again and loading the recent file, > Qtractor showed the complete waveform. While I unmuted pink noise > Qtractor crashed (auto-closed). > -------- Original Message -------- Subject: tar.gz including the sound quality test is to long Date: Tue, 20 Oct 2009 02:55:21 +0200 From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> To: Rui Nuno Capela <rncbc(a)rncbc.org> CC: qtractor-devel(a)lists.sourceforge.net Your message To: Rui Nuno Capela Subject: Sound quality of audio recordings at 96 Khz/ 24 Bit internal Linux did not reach the following recipient(s): rncbc(a)rncbc.org on Tue, 20 Oct 2009 02:36:57 +0200 This message is larger than the current system limit or the recipient's mailbox is full. Create a shorter message body or remove attachments and try sending it again. It's the same for the dev list. The tar.gz is < 13 MB. Here is the mail without the attached archive: -------- Original Message -------- Subject: Sound quality of audio recordings at 96 Khz/ 24 Bit internal Linux - b4: Re: [solved] 'offset/ note length' issue Date: Tue, 20 Oct 2009 02:31:51 +0200 From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> To: Rui Nuno Capela <rncbc(a)rncbc.org> CC: qtractor-devel(a)lists.sourceforge.net Hi Rui :) first I got some noise references. spinymouse-sudo@64studio:/usr/src/qtractor/noise$ wget http://upload.wikimedia.org/wikipedia/commons/6/66/Whitenoisesound.ogg http://upload.wikimedia.org/wikipedia/commons/6/6c/Pink_noise.ogg http://upload.wikimedia.org/wikipedia/commons/c/c9/Brownnoise.ogg Then I set the CPU frequency scaling to "Performance" and launched JACK and after JACK I run Qtractor. spinymouse-sudo@64studio:/usr/src/qtractor/noise$ jackd -Rdalsa -dhw:0 -r96000 -p512 -n2 -Xseq spinymouse-sudo@64studio:/usr/src/qtractor$ qtractor -v Qt: 4.4.0 Qtractor: 0.4.3.1409 spinymouse-sudo@64studio:/usr/src/qtractor$ qtractor I Imported the three noise.oggs. Qtractor didn't show the waveform for the brown noise recording completely, I don't know the reason why and I never had this bug or user error before, but it's also the first time I used 0.4.3.1409. I tried to record it 2 times. I did stereo recordings for the mono clips too, because this shouldn't cause any changes for the audible result. Okay, a completely new problem occurred. There's an audible loss for the quality of the sound, but in this case because of an understandable reason. The .ogg files are to loud with faders set to +- 0 db. The important thing with this is, that the loss of the sound quality for the white noise is comparable with the kind of loss I've got when doing a recording of music, even if the maximal signal level is under -3 dBFS. So it doesn't matter if the meters are Full-Scale Square wave or Full-Scale Sine Wave meters. Anyway, I wonder where the boost is from. When I recorded music by connecting Qtractors outputs to its inputs both, source clip and target clip were 96-24-stereo.wav files. There never was a visible difference for the volume. Before I go on comparing music recorded by Qtractor and Audacity, I want some information because of the strange level for the .ogg files from wiki. The qtractor session is attached as tar.gz. I suppose you'll have a directory /usr/src/qtractor too, thus you just need to add a directory /usr/src/qtractor/noise. spinymouse-sudo@64studio:/usr/src/qtractor/noise$ ls -l total 17716 -rw-r--r-- 1 spinymouse-sudo src 155775 2006-10-27 00:24 Brownnoise.ogg -rw-r--r-- 1 spinymouse-sudo src 8604 2009-10-20 02:21 noise_test.qtr -rw-r--r-- 1 spinymouse-sudo src 5844866 2009-10-20 01:51 noise_test_qtr-Recorded_brown-1.wav -rw-r--r-- 1 spinymouse-sudo src 5884802 2009-10-20 01:45 noise_test_qtr-Recorded_pink-1.wav -rw-r--r-- 1 spinymouse-sudo src 5890952 2009-10-20 01:44 noise_test_qtr-Recorded_white-1.wav -rw-r--r-- 1 spinymouse-sudo src 161738 2005-07-01 04:36 Pink_noise.ogg -rw-r--r-- 1 spinymouse-sudo src 130717 2006-10-27 00:09 Whitenoisesound.ogg spinymouse-sudo@64studio:/usr/src/qtractor/noise$ tar czf ~/Desktop/noise_test_qtr.tar.gz * Cheers, Ralf

16 years, 4 months

[LAD] announcing neil

by Vytautas Jancauskas

Hi, I have been developing a fork of the Aldrin tracker. If anyone is interested you can take a look at it at http://sites.google.com/site/neilsequencer/ It's main aim is to keep a stable and usable project with a good plugin set. Vytautas

16 years, 4 months

[LAD] non-sequencer tempo drift

by nick bailey

I've been playing with Non-sequencer over the last few days, love the simplicity and uncluttered approach to the programme, however I'm finding if run alongside Hydrogen or Ardour, the tempo drifts out of sync, this occurs playing any song longer than a couple of patterns. The obvious answer to this is to have ardour as jack transport master, Non-sequencer does not like this however and crashes. I post the question here rather than Linux Audio Users because I plan to write applications utilising Jack MIDI myself and am wondering the best approach to implement tempo in absence of alsa sequencer, which I found quite nice to use but still jittery even with high res timers / real time kernels.

16 years, 4 months

[LAD] using alsa-midi-latency-test to test the latency of PianoBooster.

by Louis B.

Hi Jakob + all Just to let you know I have managed use alsa-midi-latency-test to test the latency of PianoBooster which is very bad at the moment but here are the results anyway: I know the timer tick is much to slow at the moment so I fix that problem and retest. I have used the midi through and a midi loop back cable to put alsa-midi-latency-test and PianoBooster into the midi test loop. My results for comparison without PianoBooster in the loop are pasted in at the end of this email Louis ==== RESULTS WITH PIANOBOOSTER ===== ./alsa-midi-latency-test -i 14:0 -o 24:1 -R -w 1 -r sched_setscheduler: Operation not permitted > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > interval between measurements: 1.000 .. 2.000 ms > sampling 10000 midi latency values - please wait ... > press Ctrl+C to abort test sample; latency_ms; latency_ms_worst 0; 14.39; 14.39 90; 19.98; 19.98 91; 23.72; 23.72 9999; 10.22; 23.72 > done. > latency distribution: ... 4.2 - 4.3 ms: 1 # 4.3 - 4.4 ms: 1 # 4.4 - 4.5 ms: 2 # 4.5 - 4.6 ms: 1 # ... 5.2 - 5.3 ms: 2 # 5.3 - 5.4 ms: 3 # 5.4 - 5.5 ms: 1 # 5.5 - 5.6 ms: 2 # 5.6 - 5.7 ms: 2 # 5.7 - 5.8 ms: 2 # ... 5.9 - 6.0 ms: 3 # 6.0 - 6.1 ms: 1 # 6.1 - 6.2 ms: 2 # 6.2 - 6.3 ms: 7 # 6.3 - 6.4 ms: 3 # 6.4 - 6.5 ms: 9 # 6.5 - 6.6 ms: 1 # 6.6 - 6.7 ms: 11 # 6.7 - 6.8 ms: 7 # 6.8 - 6.9 ms: 8 # 6.9 - 7.0 ms: 11 # 7.0 - 7.1 ms: 7 # 7.1 - 7.2 ms: 9 # 7.2 - 7.3 ms: 11 # 7.3 - 7.4 ms: 15 # 7.4 - 7.5 ms: 8 # 7.5 - 7.6 ms: 12 # 7.6 - 7.7 ms: 9 # 7.7 - 7.8 ms: 9 # 7.8 - 7.9 ms: 20 # 7.9 - 8.0 ms: 19 # 8.0 - 8.1 ms: 27 ## 8.1 - 8.2 ms: 20 # 8.2 - 8.3 ms: 23 # 8.3 - 8.4 ms: 25 ## 8.4 - 8.5 ms: 28 ## 8.5 - 8.6 ms: 31 ## 8.6 - 8.7 ms: 47 ### 8.7 - 8.8 ms: 37 ## 8.8 - 8.9 ms: 40 ### 8.9 - 9.0 ms: 39 ## 9.0 - 9.1 ms: 49 ### 9.1 - 9.2 ms: 55 #### 9.2 - 9.3 ms: 81 ##### 9.3 - 9.4 ms: 68 #### 9.4 - 9.5 ms: 114 ####### 9.5 - 9.6 ms: 100 ###### 9.6 - 9.7 ms: 128 ######## 9.7 - 9.8 ms: 147 ######### 9.8 - 9.9 ms: 238 ############### 9.9 - 10.0 ms: 351 ###################### 10.0 - 10.1 ms: 492 ############################### 10.1 - 10.2 ms: 578 ##################################### 10.2 - 10.3 ms: 681 ############################################ 10.3 - 10.4 ms: 781 ################################################## 10.4 - 10.5 ms: 696 ############################################# 10.5 - 10.6 ms: 710 ############################################# 10.6 - 10.7 ms: 737 ############################################### 10.7 - 10.8 ms: 692 ############################################ 10.8 - 10.9 ms: 567 #################################### 10.9 - 11.0 ms: 525 ################################## 11.0 - 11.1 ms: 322 ##################### 11.1 - 11.2 ms: 201 ############# 11.2 - 11.3 ms: 152 ########## 11.3 - 11.4 ms: 105 ####### 11.4 - 11.5 ms: 82 ##### 11.5 - 11.6 ms: 91 ###### 11.6 - 11.7 ms: 87 ###### 11.7 - 11.8 ms: 55 #### 11.8 - 11.9 ms: 41 ### 11.9 - 12.0 ms: 36 ## 12.0 - 12.1 ms: 34 ## 12.1 - 12.2 ms: 44 ### 12.2 - 12.3 ms: 48 ### 12.3 - 12.4 ms: 33 ## 12.4 - 12.5 ms: 35 ## 12.5 - 12.6 ms: 30 ## 12.6 - 12.7 ms: 31 ## 12.7 - 12.8 ms: 18 # 12.8 - 12.9 ms: 31 ## 12.9 - 13.0 ms: 23 # 13.0 - 13.1 ms: 22 # 13.1 - 13.2 ms: 17 # 13.2 - 13.3 ms: 12 # 13.3 - 13.4 ms: 11 # 13.4 - 13.5 ms: 11 # 13.5 - 13.6 ms: 9 # 13.6 - 13.7 ms: 17 # 13.7 - 13.8 ms: 7 # 13.8 - 13.9 ms: 10 # 13.9 - 14.0 ms: 8 # 14.0 - 14.1 ms: 7 # 14.1 - 14.2 ms: 7 # 14.2 - 14.3 ms: 11 # ... 14.4 - 14.5 ms: 6 # 14.5 - 14.6 ms: 6 # 14.6 - 14.7 ms: 3 # 14.7 - 14.8 ms: 1 # ... 14.9 - 15.0 ms: 4 # ... 15.1 - 15.2 ms: 2 # 15.2 - 15.3 ms: 1 # ... 15.4 - 15.5 ms: 5 # 15.5 - 15.6 ms: 2 # 15.6 - 15.7 ms: 1 # 15.7 - 15.8 ms: 2 # 15.8 - 15.9 ms: 3 # ... 16.3 - 16.4 ms: 1 # ... 16.5 - 16.6 ms: 1 # 16.6 - 16.7 ms: 1 # ... 18.9 - 19.0 ms: 1 # ... 19.3 - 19.4 ms: 1 # ... 19.5 - 19.6 ms: 1 # ... 20.0 - 20.1 ms: 1 # 20.1 - 20.2 ms: 1 # ... 23.0 - 23.1 ms: 1 # ... 23.7 - 23.8 ms: 1 # > FAIL best latency was 4.18 ms worst latency was 23.72 ms, which is too much. Please check: - if your hardware uses shared IRQs - `watch -n 1 cat /proc/interrupts` while running this test to see, which IRQs the OS is using for your midi hardware, - if you're running this test on a realtime OS - `uname -a` should contain '-rt', - your OS' scheduling priorities - `chrt -p [pidof process name|IRQ-?]`. Have a look at http://www.linuxaudio.org/mailarchive/lat/ to find out, howto fix issues with high midi latencies. ==== RESULTS WITHOUT PIANOBOOSTER ===== ./alsa-midi-latency-test -o 24:0 -i 24:0 -R -w 1 -r sched_setscheduler: Operation not permitted > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > interval between measurements: 1.000 .. 2.000 ms > sampling 10000 midi latency values - please wait ... > press Ctrl+C to abort test sample; latency_ms; latency_ms_worst 0; 3.69; 3.69 1; 3.80; 3.80 5; 4.82; 4.82 107; 6.17; 6.17 238; 6.30; 6.30 496; 6.52; 6.52 4712; 6.79; 6.79 8429; 6.82; 6.82 9999; 3.74; 6.82 > done. > latency distribution: ... 3.0 - 3.1 ms: 12 # 3.1 - 3.2 ms: 921 ############################################# 3.2 - 3.3 ms: 961 ############################################### 3.3 - 3.4 ms: 969 ############################################### 3.4 - 3.5 ms: 994 ################################################# 3.5 - 3.6 ms: 948 ############################################## 3.6 - 3.7 ms: 944 ############################################## 3.7 - 3.8 ms: 944 ############################################## 3.8 - 3.9 ms: 1022 ################################################## 3.9 - 4.0 ms: 981 ################################################ 4.0 - 4.1 ms: 966 ############################################### 4.1 - 4.2 ms: 137 ####### 4.2 - 4.3 ms: 22 # 4.3 - 4.4 ms: 18 # 4.4 - 4.5 ms: 22 # 4.5 - 4.6 ms: 14 # 4.6 - 4.7 ms: 10 # 4.7 - 4.8 ms: 11 # 4.8 - 4.9 ms: 16 # 4.9 - 5.0 ms: 7 # 5.0 - 5.1 ms: 9 # 5.1 - 5.2 ms: 14 # 5.2 - 5.3 ms: 9 # 5.3 - 5.4 ms: 3 # 5.4 - 5.5 ms: 7 # 5.5 - 5.6 ms: 5 # 5.6 - 5.7 ms: 4 # 5.7 - 5.8 ms: 4 # 5.8 - 5.9 ms: 6 # 5.9 - 6.0 ms: 3 # ... 6.1 - 6.2 ms: 2 # 6.2 - 6.3 ms: 7 # 6.3 - 6.4 ms: 2 # ... 6.5 - 6.6 ms: 1 # ... 6.7 - 6.8 ms: 3 # 6.8 - 6.9 ms: 2 # > FAIL best latency was 3.04 ms worst latency was 6.82 ms, which is too much. Please check:

16 years, 4 months

[LAD] Next year's LAC

by victor

... seems to have been announced. I got an email from ICMA about it. Why was it not announced here or in the Consortium list? I would have thought these are the main places where you find good interest. Any further news? Victor

16 years, 4 months

Jump to page:

2026

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