Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7520 discussions

Re: [linux-audio-dev] set_rtlimit problem

by Jonathan Woithe

Hi Lee > I just noticed that the sys_get_priority_max and _min syscalls do not > take the RT priority rlimit into account. Since the watchdog thread > runs at the -P setting + 10 then if the rlimit is 50 and the user > specifies -P50 the watchdog thread will fail. > > I believe sched_get_priority_max(SCHED_FIFO) needs to take the rlimit > into account - there's no other way to get the upper limit AFAICT. I'm not sure what the "set_rtlimit problem" is here - I'm a little confused. In terms of what set_rtlimits does, it seems to me that the watchdog thread issue can be easily dealt with: define the max rtpriority value in /etc/set_rtlimits to be X, knowing that the maximum jackd "-P" option value one can use is X-10. Certainly getrlimit()/setrlimit() (which set_rtlimit uses to do its thing) seem to take the current rtpriority rlimit into account. The former also returns the rlimit hard limit for the process, which I interpret to be the "upper limit" mentioned in the original email. In testing I've done during development, set_rtlimits seems to do the right thing, based on my understanding of what the right thing is. If I've misunderstood something though I'm happy to be corrected. Regards jonathan

20 years

[linux-audio-dev] [ANN] QjackCtl 0.2.19a fix released!

by Rui Nuno Capela

Hi, Just to let you know about this small-fix release on QjackCtl, that only affects the MIDI connections (re)nomenclature: - ALSA sequencer client/port name aliases are functional again; all actual MIDI sequencer client/port numerical identifier prefixes are also back in business. Apparentely, this has been missed for quite a while, almost since 0.2.16. Only noticed this late week, thanks to Domenico Culturato. You can pick it out from the usual place: http://qjackctl.sourceforge.net Enjoy, -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

20 years

[linux-audio-dev] hdsploader not doing it

by Janina Sajka

Regret to report I am having problems loading firmware for my multiface again. This time I have the pci card in a 32-bit system running FC4 with a recent 2.6.12 kernel and alsa from 1.0.10rc1, including alsa-tools-1.0.10rc1. The error is: Hammerfall-DSP: wait for FIFO status <= 0 failed after 30 iterations Hwdep ioctl error on card hw:1 : Input/output error. -- Janina Sajka Phone: +1.202.494.7040 Partner, Capital Accessibility LLC http://www.CapitalAccessibility.Com Chair, Accessibility Workgroup Free Standards Group (FSG) janina(a)freestandards.org http://a11y.org If Linux can't solve your computing problem, you need a different problem.

20 years

[linux-audio-dev] set_rtlimit problem

by Lee Revell

Hey, I just noticed that the sys_get_priority_max and _min syscalls do not take the RT priority rlimit into account. Since the watchdog thread runs at the -P setting + 10 then if the rlimit is 50 and the user specifies -P50 the watchdog thread will fail. I believe sched_get_priority_max(SCHED_FIFO) needs to take the rlimit into account - there's no other way to get the upper limit AFAICT. Lee

20 years

[linux-audio-dev] Echo Gina3G

by conrad berhörster

Hello all, sorry for crossposting. Is there any experience with the Echo Gina3G card. link: http://www.echoaudio.com/Products/PCI/Gina3G/ thanks c~

20 years

[linux-audio-dev] xruns

by conrad berhörster

Hello list, well i try to understand the reason of xruns. when will they appear? for me it's curious, that , while copy a big file (> 50MB ) or many small one, there are xruns. so, it seems, that it has nothing to do with the soundcard buffers. any comments? sizu c~

20 years, 1 month

[linux-audio-dev] LASH and LASH_Terminal client flag problem

by Florian Schmidt

Hi, in the course of LASH'ifying jack_convolve i stumbled across the LASH_Terminal client flag which specifies to LASH that the client wants to be run in its own terminal when the session is restored. The code for this is in liblash/loader.c:121 The problem i see is: when the client in the term exits (either by means of LASH telling it to, or by sending i.e. a SIGINT), it just drops to a bash prompt instead of exiting the terminal. For reference i have included the code in question below. I also wonder why it is necessary to start another bash anyways? I tried to remove the extra bash call and use xterm -e command_buffer directly, but then the program doesn't even start correctly. Any other thought on this? static void loader_exec_program_in_xterm(int argc, char **argv) { size_t command_size; char *command_buffer; char *xterm_argv[6]; command_size = get_command_size(argc, argv); command_buffer = lash_malloc(command_size); create_command(command_buffer, argc, argv); xterm_argv[0] = "xterm"; xterm_argv[1] = "-e"; xterm_argv[2] = "bash"; xterm_argv[3] = "-c"; xterm_argv[4] = command_buffer; xterm_argv[5] = NULL; /* execute it */ execvp("xterm", xterm_argv); ... Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org

20 years, 1 month

[linux-audio-dev] Linux soundapps pages updated

by Dave Phillips

Greetings: Once again, the inevitable update: http://linuxsound.atnet.at (Europe) http://linuxsound.jp (Japan) http://linux-sound.org (US) No Musings column this time. :( Lots of nice New Additions. :) Best, dp

20 years, 1 month

[linux-audio-dev] Jack and NPTL (again?)

by Jonathan Woithe

Hi everyone I've recently moved a system over to Slackware 10.2 which utilises NPTL and I'm aware of the issues NPTL has raised in the past. Based on a comment on the Jack website though I sort of assumed that things were now in hand and that Jack had a workaround in place for the issue. Despite this I have found that jackd itself (when run using set_rtlimits) gives an error (-11, EAGAIN) when "creating realtime thread". I have already confirmed that set_rtlimits does operate correctly in the NPTL environment; it appears that for some reason pthread_create flatly refuses to create the RT thread even though the appropriate priority limits are set for the process. The LD_ASSUME_KERNEL hack does make jackd work; however, it would be nice to know what's going on (or whether in fact the problems are still being worked on). Are there any ideas? Interestingly enough, jack applications (ardour for example) do NOT need the LD_ASSUME_KERNEL hack - they start and operate fine without out. Only jack itself appears to have issues. Glibc is 2.3.5, getconf reports "NPTL 2.3.5" and kernel is 2.6.14 plus 2.6.14-rt13. 2.6.14-rc3-rt4 has the same issues. Oddly enough, it appears that under 2.6.13 things work fine even for jackd, but I need to confirm that tonight. Jack command line (from memory): jackd -R -d alsa -d hw:0 -n 4 -p 512 Jackd compiled against 2.6.14 headers with gcc 3.3.6. Kernel compiled with 3.3.6 also. Regards jonathan

20 years, 1 month

[linux-audio-dev] /. article and paper

by Lee Revell

Linked from this article: http://linux.slashdot.org/article.pl?sid=05/11/20/2255217 I found this paper from MontaVista. In addition to being a good high level overview of how modern Linux kernels achieve low latency they give special credit to the Linux audio developer community and Paul Davis's open letter to the kernel developers for driving the evolution of Linux 2.6 into a viable soft RT platform. http://linuxdevices.com/articles/AT9697872711.html Lee

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