Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7520 discussions

PCI MIDI jitter - comparison Ubuntu (bad) and Suse (might be ok)

by Ralf Mardorf

Hi :) today I compared a default Ubuntu Studio with and without the proprietary NVIDIA driver. Note that for Ubuntu Studio 2 tests failed because of time out errors, but even the tests that were passed with success are significantly less good, than the tests with openSUSE, were I set up audio myself. Ubuntu based Linux until now were my music Linux, e.g 64 Studio 3.0 and 3.3, but I wonder if bad MIDI latency is depending to Ubuntu. For Ubuntu Studio even PCI MIDI has got more jitter, but USB MIDI for Suse, see older test in the archives. What might be the difference between Ubuntu and Suse? Could anybody compare different distros too? ------------------------------------------------------------------------ Ubuntu Studio 10.04 amd64 2 x Terratec EWX 24/96 (2 single cards, but 1 virtual card) Frequency scaling ? ------------------------------------------------------------------------ spinymouse@ubuntu:~$ hwinfo --gfxcard Driver: "nouveau" Driver Modules: "drm" IRQ: 18 spinymouse@ubuntu:~$ alsa-midi-latency-test -l Port Client name Port name 14:0 Midi Through Midi Through Port-0 16:0 TerraTec EWX24/96 TerraTec EWX24/96 MIDI 20:0 TerraTec EWX24/96 TerraTec EWX24/96 MIDI 128:0 TiMidity TiMidity port 0 128:1 TiMidity TiMidity port 1 128:2 TiMidity TiMidity port 2 128:3 TiMidity TiMidity port 3 spinymouse@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o20:0 -i20:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > SUCCESS best latency was 1.00 ms worst latency was 1.97 ms, which is great. spinymouse@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o20:0 -i20:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > SUCCESS best latency was 1.00 ms worst latency was 3.36 ms, which is great. spinymouse@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o16:0 -i16:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > SUCCESS best latency was 0.99 ms worst latency was 1.93 ms, which is great. spinymouse@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o16:0 -i16:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > SUCCESS best latency was 0.99 ms worst latency was 1.74 ms, which is great. spinymouse@ubuntu:~$ uname -a Linux ubuntu 2.6.32-23-preempt #37-Ubuntu SMP PREEMPT Fri Jun 11 10:19:07 UTC 2010 x86_64 GNU/Linux spinymouse@ubuntu:~$ envy24control 0xcf00, irq 20, Master Clock int 44100 No envy24control for 0xcb00, irq 21, Master Clock ? 20:0 opto S/PDIF out --> 16:00 opto S/PDIF in ------------------------------------------------------------------------ Ubuntu Studio 10.04 amd64 2 x Terratec EWX 24/96 (2 single cards, but 1 virtual card) Frequency scaling ? ------------------------------------------------------------------------ spinymouse@ubuntu:~$ hwinfo --gfxcard Driver: "nvidia" Driver Modules: "nvidia" IRQ: 18 spinymouse@ubuntu:~$ alsa-midi-latency-test -l Port Client name Port name 14:0 Midi Through Midi Through Port-0 16:0 TerraTec EWX24/96 TerraTec EWX24/96 MIDI 20:0 TerraTec EWX24/96 TerraTec EWX24/96 MIDI 128:0 TiMidity TiMidity port 0 128:1 TiMidity TiMidity port 1 128:2 TiMidity TiMidity port 2 128:3 TiMidity TiMidity port 3 pinymouse@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o20:0 -i20:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > SUCCESS best latency was 1.00 ms worst latency was 1.84 ms, which is great. spinymouse@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o20:0 -i20:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > SUCCESS best latency was 1.00 ms worst latency was 1.27 ms, which is great. spinymouse@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o16:0 -i16:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > SUCCESS best latency was 0.99 ms worst latency was 1.92 ms, which is great. spinymouse@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o16:0 -i16:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > SUCCESS best latency was 0.99 ms worst latency was 1.72 ms, which is great. spinymouse@ubuntu:~$ uname -a Linux ubuntu 2.6.32-23-preempt #37-Ubuntu SMP PREEMPT Fri Jun 11 10:19:07 UTC 2010 x86_64 GNU/Linux spinymouse@ubuntu:~$ envy24control 0xcf00, irq 20, Master Clock int 44100 No envy24control for 0xcb00, irq 21, Master Clock ? 20:0 opto S/PDIF out --> 16:00 opto S/PDIF in ------------------------------------------------------------------------ openSUSE 11.2 amd64 2 x Terratec EWX 24/96 (2 single cards, but 1 virtual card) Frequency scaling performance ------------------------------------------------------------------------ spinymouse11.2@suse11-2:~> su -c "hwinfo --gfxcard" Driver: "nvidia" Driver Modules: "nvidia" IRQ: 18 spinymouse11.2@suse11-2:~> alsa-midi-latency-test -l Port Client name Port name 14:0 Midi Through Midi Through Port-0 16:0 TerraTec EWX24/96 TerraTec EWX24/96 MIDI 24:0 TerraTec EWX24/96 TerraTec EWX24/96 MIDI spinymouse11.2@suse11-2:~> alsa-midi-latency-test -l Port Client name Port name 14:0 Midi Through Midi Through Port-0 16:0 TerraTec EWX24/96 TerraTec EWX24/96 MIDI 24:0 TerraTec EWX24/96 TerraTec EWX24/96 MIDI spinymouse11.2@suse11-2:~> alsa-midi-latency-test -Rrw=2 -o24:0 -i24:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > SUCCESS best latency was 0.99 ms worst latency was 1.07 ms, which is great. spinymouse11.2@suse11-2:~> alsa-midi-latency-test -Rrw=2 -o24:0 -i24:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > SUCCESS best latency was 0.99 ms worst latency was 1.08 ms, which is great. spinymouse11.2@suse11-2:~> alsa-midi-latency-test -Rrw=2 -o16:0 -i16:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > SUCCESS best latency was 0.99 ms worst latency was 1.06 ms, which is great. spinymouse11.2@suse11-2:~> alsa-midi-latency-test -Rrw=2 -o16:0 -i16:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > SUCCESS best latency was 0.99 ms worst latency was 1.05 ms, which is great. spinymouse11.2@suse11-2:~> uname -a Linux suse11-2 2.6.31.6-rt19 #1 SMP PREEMPT RT Wed Nov 18 16:59:26 CET 2009 x86_64 x86_64 x86_64 GNU/Linux spinymouse11.2@suse11-2:~> envy24control spinymouse@ubuntu:~$ envy24control 0xcf00, irq 20, Master Clock int 44100 No envy24control for 0xcb00, irq 21, Master Clock ? 24:0 opto S/PDIF out --> 16:00 opto S/PDIF in I still have got some tests to do, e.g. a real test by listening to MIDI music and I'll test what happens if two sound cards become one virtual sound card, http://www.jrigg.co.uk/linuxaudio/ice1712multi.html and before doing this I need to test if the second, new second hand card from Ebay isn't broken for audio, resp. I'll compare the sound quality for my old and the new Terratec EWX 24/96 sound card, before they become one virtual sound card. Cheers! Ralf

15 years, 5 months

transport/timebase calculations

by James Morris

Hi, I can't see what's wrong with the calculations I'm performing for timebase/transport in my JACK app. I'm not sure where the error lies. I keep looking and looking at it, changing bits, experimenting, and still not getting the desired result. Everything is playing too slow. For example, @ 120bpm 4/4 time, the second (or third) bar starts almost an entire beat too late. Please could someone take a look at the calculations and see if there's something obviously wrong with them? The source can be viewed online at: http://github.com/jwm-art-net/BoxySeq/blob/master/jack_transport.c The poll function starts at line 169 the jack timebase call back starts at 226. The code was originally based on non-sequencer or dino or some combination of both. It is also a bit grumpy with other JACK apps which use transport, but I trying to fix the time keeping first. TIA, James.

15 years, 5 months

[LAA] [ANN] guitarix-0.10.0 released

by hermann

guitarix is a simple Linux Rock Guitar amplifier and is designed to achieve nice thrash/metal/rock/blues guitar sounds. guitarix uses the Jack Audio Connection Kit as its audio backend and brings to the jack audio graph a mono amplifier input/output port, and a FX mono input with two (stereo) output ports. guitarix provide a jack midi input port to connect a midi controller (midi learn) and a (3 channel) jack midi output port, feed by a (scalable) mix of the tuner and a beat-detector. Release 0.10.0 comes with following changes : * add tonestack models * add 2. amp model * add cabinet impulse response module * add Patch Info widget * add Preset File Load/Export option * add simple looper * add Oscilloscope and tuner state to main settings * selectable distortion model (multi/single line) * selectable EQ model (fixed/scalable freq) * free mem when not used (delay lines) * reworked Gui * fix various bugs have fun _________________________________________________________________________ Note:// for experienced Users there is a Experimental widget witch comes with the tremolo effect contributed by transmogrifox (Rakarrack dev-team) please look ./waf --help for how to build with this widget activated. Many thanks to transmogrifox for his contribution. _________________________________________________________________________ guitarix is licensed under the GPL. Project page with screenshots: http://guitarix.sourceforge.net/ download: http://sourceforge.net/projects/guitarix/ please report bugs and suggestions in our forum here: http://sourceforge.net/apps/phpbb/guitarix/ ________________________________________________________________________ For capture, guitarix uses the great 'jack_capture' (version >= 0.9.30) written by Kjetil S. Matheussen. If you don't have it installed, you can look here: http://old.notam02.no/arkiv/src/?M=D For extra Impulse Responses, guitarix uses the zita-convolver library, and, for up/down sampling we use zita-resampler, both written by Fons Adriaensen. If you don't have it installed, get it here: http://www.kokkinizita.net/linuxaudio/index.html We use the marvellous faust compiler to build the amp and effects and will say thanks to : Julius Smith http://ccrma.stanford.edu/realsimple/faust/ : Albert Graef http://q-lang.sourceforge.net/examples.html#Faust : Yann Orlary http://faust.grame.fr/ ________________________________________________________________________ For faust users : All used Faust dsp files are included in /guitarix/src/faust, the resulting cc files are in /guitarix/src/faust-cc The tools we use to convert (post-processing and plot) the resulting faust cpp files to the needed include format, stay in the /guitarix/tools directory. ________________________________________________________________________ regards Hermann Meyer, James Warden, Andreas Degert

15 years, 5 months

jack2 with session support?

by Jonathan E. Brickman

Is there a jack2 version with session support? J.E.B.

15 years, 5 months

Re: [LAD] [64studio-users] MIDI jitter

by Ralf Mardorf

Ichthyostega wrote: > Ralf Mardorf schrieb: >> Another stupid question induced by an argument regarding to MIDI jitter by >> Daniel James. >> >>> [snip] I'm sceptical that the realtime kernel is the cause of your MIDI >>> problems. If they got this right in the 80's, on computers which could not >>> do anything near realtime audio processing, then I think it's more likely >>> to be a question of MIDI application design. > > At that point we should call back, how that whole story with "realtime" > started. At the begining was a design mismatch. Many things related to > the Linux kernel started out with a kind of "I feel fine" pragmatism. > Which, btw isn't to criticise as it is, because this also accounts > for the freshness and sometime unconventional new approach to some > problems. But with regards to timings, for all of the first decade > of Linux development, there seemed to be a completely different > mental model, which we could summarise as: permormance == throughput, > and timings are only relevant, when you get a network timeout, or > a sluggish response in your application's GUI. > > Thus, if we now consider to use a Linux kernel for making music, we must > assess that the whole design isochronously assumed about 1000 times more > headroom as there really is. > > Thus, as writing a new Kernel doesn't seem to be an option, this whole > tedious undertaking of the "realtime patches" can be described as an > attempt to fix this "problem" (which was never assumed to be a problem > in the initial design) by hunting down one by one each individual instance > where the existing kernel could possibly be reacting too slow. > > Thus, we should rather be surprised, how good these realtime kernels work. > OTOH, is isn't a surprise the machines from the 80s meet these criteria; > their OS software was written with an awareness for a much more limited > processing capability right from start. > > >> Why do people (not only me) report jitter for external MIDI equipment, but I >> couldn't find any report for real-time audio jitter? Resp. what's about async >> and disconnecting clients by JACK? > > Audio and MIDI are two quite different beasts. > Sound is processed in Blocks, where the individual unity (1 Sample) is > much more fine grained and way below anything which can be discerned by > a human ear. Moreover, Sound as such already exists and 'just' has to > be piped through. To the contrary, MIDI consists of events, which > immediately trigger a reaction, which could be that a piece of software > and at the same time a piece of external hardware starts a processing > cycle. You see, thats a completely different situation and thus it's > obvious, why for these two media the same problem causes so different > symptoms. > >> OTOH on Windows audio clients don't disconnect, >> just MIDI jitter is an issue too. > > IIRC, this was a design decision for JACK. It never tries to conceal > any timeout problem, rather it requires its clients to keep up with > a very tight schedule and comply to very strict rules. > > I don't know the MIDI part of Jack well enough to judge, if it was > designed with the same "you're required to comply" policy. And besides, > when the MIDI interface is hooked up via USB, we again face a completely > different situation. USB is a complicated protocol, which multiple > versions and levels and is certainly not designed to get an individual > event transfered reliably with less than 2ms jitter. > There is even the possibility that the USB peers negotiate to use a > lower transfer rate or protocol version transparently, when they > determine the connection can't keep up with the higher speed. > > Cheers > Hermann V. It's said that USB MIDI interfaces should be the better choice. But this explains a lot. Dunno how to read Fons JACK MIDI jitter test, but ... Subject: Re: [LAD] Again MIDI jitter - tested with Fons test applications Date: Sat, 27 Mar 2010 18:26:33 +0100 From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> To: fons(a)kokkinizita.net CC: linux-audio-dev(a)lists.linuxaudio.org References: <4BADBD42.4030505(a)alice-dsl.net> <20100327164326.GD1545@zita2> > Hi Fons :) > > fons(a)kokkinizita.net wrote: > > On Sat, Mar 27, 2010 at 09:09:38AM +0100, Ralf Mardorf wrote: > > > > > >> Regular it shifted between 2395 and 2404, but with a few exceptions, > >> one time 2302, three times 2304, two times 2305 and two time 2494. > >> See attachment. > >> What might cause this exceptions? Could it be access to the RAM by > >> the graphics? Is there something bad because of the IRQs? > >> > >> Regular shift 2404 - 2395 = 9 frames of jitter, exceptional maximal > >> shift 2494 - 2302 = 192 frames of jitter. > >> > >> I guess this does mean ... > >> 5.3 ms / 512 frames = 0.010351562 ms/frame > >> Maximal difference for regular jitter 0.093164062 ms. > >> Maximal difference for exceptional jitter 1.9875 ms. > >> ... am I wrong? > >> > > > > Wrong once or twice, if twice in such a way that the two > > errors cancel out. > > > > First note that the test prints the difference between > > events. That means that e.g. if *one* note is 100 samples > > late you could see 2400 2500 2300 2400. > > > > The '2300' is just because the previous one was late, > > not because this one arrives too early. So you should > > divide the jitter as you measure it by two. > > > > Aha, okay this is plausible. > > > Second, 5.33 ms = 256 frames at 48 kHz. But maybe you > > are using 96 kHz ?? > > > > So you didn't read the attachment ;), yes I did use 96 KHz. > [snip] Subject: Again MIDI jitter - tested with Fons test applications Date: Sat, 27 Mar 2010 09:09:38 +0100 From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> To: Linux Audio Developers <linux-audio-dev(a)lists.linuxaudio.org> > When I once tested it by recording I got this result for ALSA MIDI on > Linux, Cubase runs on Windows on the same machine: > > ||Cubase|HR tmr|System|PCM pl|PCM ca > ------++------+------+------+------+------ > 500.0 || 493.0| 504.9| 505.6| 503.4| 503.2 > 1000.0|| 993.4|1005.4|1005.8|1005.3|1006.4 > 1500.0||1494.5|1503.6|1506.4|1507.4|1507.3 > 2000.0||1994.8|2003.8|2007.2|2007.9|2009.5 > 2500.0||2492.4|2504.1|2504.3|2503.6|2503.2 > 3000.0||2992.9|3006.0|3006.2|3005.9|3007.6 > 3500.0||3493.7|3502.7|3505.4|3506.5|3509.5 > 4000.0||3994.6|4003.1|4003.2|4008.8|4009.9 > msec +/- 0.1 msec > maxDif|| 4.8| 6.0| 7.2| 8.8| 9.9 > minDif|| -2.4| -2.7| -3.2| -3.4| -3.2 > --------------+------+------+------+------ > Jitter|| 2.4| 3.3| 4.0| 5.4| 6.7 > msec +/- 0.2 msec ... as you can see, for Cubase I got this 2ms of jitter. So regarding to your explanation Herman, Windows + ASIO + Cubase does a good job, just the USB interface will limit it, while for Linux there seems to be another issue too, but the USB interface. Btw. Linux HR tmr is a PITA, just System, PCM pl and PCM ca are usable without issues for all Linux apps. What could be the cause that Windows just is limited to the USB interface by 2.4 ms, but Linux comes with 4.0 ms on my machine? Joshua Boyd on LAD wrote: > On Thu, Jun 17, 2010 at 10:37:25AM -0400, Gene Heskett wrote: > >>> At my school we transfered the CAD files per floppy to a DOS box that >>> controlled the CNC machine, guess that's for the same reason, bad rt >>> capabilities of newer OSes and machines. >> The RTAI works pretty well, I can start a job, switch away from that window, >> and talk to the guys on IRC, or browse the web without hurting the job. >> That to me is true multitasking. > > So, that leaves me wondering why no one seems to be trying RTAI for > audio work? Or is someone doing that and I'm just not aware? Today I tried to do so. I tried to run JACK2 with -R switch by user and by sudo, the result was the same as here, when I launched JACK2 without -R switch on 64 Studio 3.0 beta based on Ubuntu Hardy: $ uname -r 2.6.24-16-rtai $ jackd -dalsa -dhw:0 -r96000 -p512 -n2 jackdmp 1.9.3 Copyright 2001-2005 Paul Davis and others. Copyright 2004-2009 Grame. jackdmp comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details JACK server starting in non-realtime mode creating alsa driver ... hw:0|hw:0|512|2|96000|0|0|nomon|swmeter|-|32bit control open "hw:0" (No such file or directory) Cannot initialize driver no message buffer overruns JackServer::Open() failed with -1 Failed to start server ALSA seq couldn't start too. I run the EMC2 / HAL latency-test: Servo thread (1.0 ms): max interval 999180 ns, max jitter 10949 ns, last interval 992259 ns Base thread (25.0 us): max interval 34551 ns, max jitter 9640 ns, last interval 24887 ns The same test couldn't be used for my kernel-rt: $ uname -r 2.6.31.12-rt20 $ latency-test insmod: can't read '/usr/realtime-2.6.31.12-rt20/modules/rtai_hal.ko': No such file or directory RTAPI: ERROR: could not open shared memory (errno=2) HAL: ERROR: rtapi init failed halcmd: hal_init() failed: -9 NOTE: 'rtapi' kernel module must be loaded RTAPI: ERROR: could not open shared memory (errno=2) HAL: ERROR: rtapi init failed halcmd: hal_init() failed: -9 NOTE: 'rtapi' kernel module must be loaded RTAPI: ERROR: could not open shared memory (errno=2) HAL: ERROR: rtapi init failed halcmd: hal_init() failed: -9 NOTE: 'rtapi' kernel module must be loaded ERROR: Module hal_lib does not exist in /proc/modules ERROR: Module rtapi does not exist in /proc/modules ERROR: Module rtai_math does not exist in /proc/modules ERROR: Module rtai_sem does not exist in /proc/modules ERROR: Module rtai_fifos does not exist in /proc/modules /usr/bin/emc_module_helper: Invalid usage with args: remove rtai_ksched [snip] ERROR: Module rtai_hal does not exist in /proc/modules Btw. should I commend out the EMC2 memlock when doing audio work again or doesn't have it an impact? $ cat /etc/security/limits.conf | grep memlock # - memlock - max locked-in-memory address space (KB) @audio - memlock unlimited # @audio - memlock 2000000 * hard memlock 20480 #EMC2 Cheers! Ralf PS: What now? It's my second hardware set up. I just bought a new computer a long time ago, because the old computer wasn't ok for Linux too, but I don't have the money to pay for one machine after the other, until I might have good luck. Both machines are 100% stable for Windows, for Linux I also get asyncs + distortion when using JACK2. I didn't test if current JACK1 is ok, or if it would disconnect clients. Don't get me wrong, I never was a private Windows user, it just were installs for testings. I'm using Linux only at home.

15 years, 5 months

midi stream error analysis

by James Morris

Hi, Is there any software which will tell me of 'errors' in the midi stream? I'm having trouble with notes which hold for too long and want an easy way of eliminating (or not) missing note-off events. Cheers, James.

15 years, 5 months

Denemo 0.8.18 Release - Free and Open Music Notation Editor

by Nils Hammerfest

Get Denemo 0.8.18 http://denemo.org/index.php/Get_Denemo Release Notes: -Default behavior is now non-modal * You can choose one out of four Shortcut systems, including the "Classic" one. * an easy to understand and very slick interface via keyboard * seamless integration with MIDI controllers -Better Paste command. -Musical Snippets - store musical riffs/motifs to be pasted at will or as rhythmic templates for playing over. Maximize the space for the score (with/without user's choice of menus). * Standard View - window size, zoom, number of systems etc * No-Menu version of this view * Page View - user chooses a window size, zoom and number of systems, which is stored with the movement for instant recall. * Single keyboard shortcut for toggling between these views (Esc by default). -MIDI transport work for JACK users. -Fix Chord Symbols for music starting with triplets, grace notes etc. -Fix display of dotted rests -Arbitrary Tuplets built in: correct MIDI output as well as engraving, of course. -Diatonic Transposition: Shift notes and chords up and down respecting the current key signature. -Support for figured bass extenders, including those with no starting figure. -Cursor can be highlighted, making it easier to locate -Page turning is animated: as the last line starts to play, the page visibly turns at the top. -Purely rhythmic notes playback using percussion - click tracks more easily generated. -Split Notes and Chords to smaller notes while preserving the original duration (make a quarter note two 8th or tuplet of 8th or 7-tuplet) -Duplicate a Note or Chord as command -Command line interface for interactive scheme use -Support for the "French" clef (G on bottom line)

15 years, 5 months

Re: [LAD] [LAA] gst123-0.1.2

by Niels Mayer

On Mon, Jul 5, 2010 at 9:11 AM, Stefan Westerfeld <stefan(a)space.twc.de> wrote: > gst123-0.1.2 has been released. > Website: http://space.twc.de/~stefan/gst123.php > Download: http://space.twc.de/~stefan/gst123/gst123-0.1.2.tar.bz2 Stefan -- very nice and useful program. Thanks for making this available! FYI -- To compile on Fedora, I had to install the following to get 'configure' to stop complaining: 1) yum install 'gstreamer-devel' (obviously) 2) yum install gstreamer-plugins-base-devel (less obvious as config complains: No package 'gstreamer-interfaces-0.10' found // No package 'gstreamer-video-0.10' found ) 3) yum install ncurses-devel The application compiles and works nicely after that. However, I have some questions/issues/bugs: (1) I do not have pulseaudio running, and all gstreamer apps have a pause as they attempt to contact pulseaudio, and then emit a message: "socket(): Address family not supported by protocol" ... in a GUI app, this might make less of a difference, since you don't end up having the app respond to ^C signals. However, gst123 does -- and during the period when gstreamer is contacting the pulseaudio socket, the application becomes temporarily unresponsive, even to signals like ^C. By the time it starts responding again it's already loaded the next file and gone unresponsive again due to timing out on the nonexistent pulseaudio socket. This makes the program very hard to interrupt. Question: is there a way to disable checking for pulseaudio for each new file when specifying multiple media files. e.g.: "gst123 *.ogg" ? For example: do it once at application startup, or even better, a way to prevent it from happening all-together via environment variable, configuration, etc. Best would be some kind of environmental check so that the timeout on socket needn't occur.The timeout significantly slows down operation of the program even when not issuing ^C's. (2) For HD Video recorded off digital broadcasts, but not for regular def broadcast video, there's a problem when issuing the '->' (forward arrow) or '<-' (backward arrow) commands to skip forwards or back: As you go forward, there's an increasingly longer delay before the audio syncs up and starts playing. Hit '->' a few times and the audio never seems to sync up, and sometimes the video stays paused on the same frame, even though the time display in the terminal continues updating. Note that the files producing these errors have some oddball results output from "ffmpeg -i" but that's how mythtv's mpg files look, for HD broadcasts: ............... [mpeg2video @ 0x1c2fcd0]mpeg_decode_postinit() failure Last message repeated 7 times [mpegts @ 0x1c2b5f0]MAX_READ_SIZE:5000000 reached Input #0, mpegts, from '/home/npm/Videos/1551_20100407195900.mpg': Duration: 02:06:59.36, start: 55515.108733, bitrate: 10490 kb/s Program 1 Stream #0.0[0x7c0]: Video: mpeg2video, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 38810 kb/s, 62.39 fps, 59.94 tbr, 90k tbn, 119.88 tbc Stream #0.1[0x7c1]: Audio: ac3, 48000 Hz, stereo, s16, 192 kb/s Stream #0.2[0x7c2]: Audio: ac3, 48000 Hz, stereo, s16, 192 kb/s At least one output file must be specified ................ (3) Note that if the above file is played out of a list 'gst123 *.mpg' then at least it gets audio playback. The same file, started standalone, shows video, but gives plays no audio: ............. gnulem-346-~> gst123 /home/npm/Videos/1551_20100407195900.mpg Playing file:///home/npm/Videos/1551_20100407195900.mpg ** (gst123:12323): CRITICAL **: gst_mpeg_descriptor_find: assertion `desc != NULL' failed ** (gst123:12323): CRITICAL **: gst_mpeg_descriptor_find: assertion `desc != NULL' failed No accelerated IMDCT transform found ** (gst123:12323): CRITICAL **: gst_mpeg_descriptor_find: assertion `desc != NULL' failed ** (gst123:12323): CRITICAL **: gst_mpeg_descriptor_find: assertion `desc != NULL' failed No accelerated IMDCT transform found socket(): Address family not supported by protocol Codec : Dolby Digital (AC-3) (audio) Bitrate : 192.0 kbit/s ............................ Niels http://nielsmayer.com PS: Feature request: decode caption information from videos, and display in video. And/or output a timed-text, SMIL or other file containing the caption information and time-of-presentation information. This can be very useful in searching content of video files.

15 years, 5 months

Feature request for FIL-Plugins

by Jostein Chr. Andersen

Hi Fons and LAD's, I'm a very happy user of the decent FIL-equalizer and so far, it serves all my needs for mixing down mono channels in mixing situations. The problem is that a Stereo EQ is also needed from time to time, for example with drums; I'm thinking about overhead channels. I use to make on bus for the drums and an additional bus for the OH channels (so left and right OH channels can use common hipass, compressor and EQs, and deesser (and so on)), then every drum item is feed into the drum bus and OH's is feed it's stereo bus and from there into the drum bus; this is probably the most common way to do it. So my humble (I hope) request is: Is it possible to make a stereo version of FIL-equalizer and can someone implement it? That would make the mixing situation very much better. And while I'm at it: Is it possible to add a Hi Pass filter (12(/18)/24 db) on them too? ;-) I know that's it's other EQ's out there, but the FIL-equalizer seems to cover up my needs while still being simple to use and not overloading the computer - 2 or 3 bands are normally everything one need. Thank you. Jostein

15 years, 5 months

calf: where did the nice hi and lowpass plugins go?

by Jörn Nettingsmeier

hi calf folks, hi everyone! unless i'm getting confused, the calf plugin set used to contain a set of hi- and lowpass filters that seem to have vanished with my last git pull. which is a major pity, since a) the current git solves a number of crashes and b) i've been using those hi- and lowpass plugins (perhaps unwisely) in a number of rather complicated sessions that i need to be able to revisit... any chance of getting those back? best, jörn

15 years, 5 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