Re: [LAD] jack_snapshot http://tapas.affenbande.org/

2011-01-26 Thread rosea.grammostola 

On 01/10/2011 12:22 AM, David Adler wrote:

On Sun, Jan 9, 2011 at 11:32 PM, Paul Davis wrote:
   

  [ ... jack_snapshot ... ]

i emailed tapas about this a few months ago, asking if we could host
it on jackaudio.org and got no reply. if someone has a copy, i'll be
happy to put it on jackaudio.org 

 

Thanks, I'll send it to you.
Maybe update it (add the two includes). I don't know if those are
a proper fix, It was just a rather blind shot that worked for me.
   


Still offline. I would be interested in the source to experiment with 
it. Could someone host it or email it to me?


Regards,

\r
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] ALSA POLLIN event problems

2011-01-26 Thread Louis Gorenfeld 
For some reason, gmail has stopped delivering my LAD messages, so
apologies if this reply isn't working correctly...

I'm attempting to run, in general, a 128 sample buffer (frames per
fragment).  There is a lower latency mode though which is 64 samples.
I have two fragments.  Maybe if I want to do this I should be using
three at least or make 128 the minimum.

But I'm a little confused at the lack of ins and outs being linked.
For a full duplex loop, I'd have to have the input before I can
process output for example, so I don't see how that works unless I
just ignore input requests from ALSA if I am not yet ready to receive.
 I'm defining "ready to receive input" as the time after I run my
processing loop and then get a POLLOUT request.  However, when I
ignore POLLINs like this, it seems like ALSA immediately POLLINs again
and I wind up with something like 50,000 polling requests handled in a
second, which drives the CPU usage through the roof.

>the in & out are not linked in any way as far as ALSA is concerned
>(even though they may be at the h/w level).
>a 64 sample buffer (not period) is very, very small. you need very
>tight code and a well configured machine to operate like this. what
>period size and/or number of periods are you attempting to use?
>> Hey, I've been having a lot of trouble with ALSA and processing input
>> in a full duplex loop, and I was wondering if anyone here had any
>> insight. I'm using the ALSA poll file descriptor method with the mmap
>> routines. Typically, my processing loop is blowing past the poll
>> statement with input requests (POLLIN), causing the CPU usage to go
>> off the charts as it's basically looping as fast as it can go.
>>
>> Now, I'm handling the inputs in a way that might not be correct.
>> Often, ALSA is saying that the available frames is 1.5 times my buffer
>> size (e.g., I set a 64 sample buffer and ALSA offers me 96 samples).
>> I only get (begin/commit) input when the buffer size matches or
>> exceeds the buffer length I send out to the card (the set buffer
>> size), and if it exceeds that, I only pick up (commit) one buffer's
>> length of frames. Is this wrong? If there is more input waiting,
>> does ALSA immediately go and POLLIN again, or should I expect it to
>> not bug me again until I've processed a POLLOUT event (the in and out
>> are linked)? I'm not really sure how to handle this..
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] [ANN] csound 5.13 release

2011-01-26 Thread Victor Lazzarini 

Basically a bug fixing release but with a number of new opcodes etc

http://souceforge.net/projects/csound

==John ffitch

Notes for 5.13
==

New Opcodes:
   farey sequence opcodes
   median opcode
   filevalid opcode
   Real random number generators using /dev/random (Linux only)
   pvstanal opcode -- phase vocoder analysis by reading function tables
   mincer opcode -- Phase-locked vocoder processing
   temposcal opcode -- Phase-locked vocoder processing with onset
 detection/processing
   pvswarp opcode -- Warp the spectral envelope of a PVS signal
   pvslock opcode -- Frequency lock an input fsig

New Gen and Macros:
   INF macro added to orchestras; z read as infinity in scores
   GEN for support of farey sequences

Modified Opcodes and Gens:
   init changed to allow multiple inits in on statement
   maxalloc, cpuperc, instcount now accept named instruments
   If normalisation in pow opcodes is zero treat as 1
   inch can take upto 20 inputs and outputs
   pvscale and pvsmix now have very good spectral envelope preservation
   modes (1 = filtered cepstrum, 2 = true envelope).
   oscil1 could be static if the duration was long; now there is a
   positive minimum increment.
   GEN49 now uses search paths
   pvsvoc enhanced with new spectral envelope preservation code.

Bugs fixed:
   Count of lines fixed in orchestras, and \ inside strings
   Fast tab opcodes made safe from crashes
   % in formated printing could crash
   Double free in fgen fixed
   sndwarp quietened (gave too many messages)
   gen41 deals with positive probabilities
   adsynt reworked removing many bugs
   adsynt2 phase error fixed
   atonex/tonex did wrong operation
   Bug in max number of gens fixed
   mp3in could repeat sound at end of file
   Better checking in grain4
   modulus was wrong in new parser
   Better checking in adsyn
   changed opcode initialised to zero
   Serious bug in tabmorphia fixed
   GEN49 has serious bug removed, so no longer incorrect silences.
   Partikkel opcode: fixed bug in sub-sample grain placement when
   using grain rate FM
   nchnls_i working correctly

System Changes:
   In the new parser only there are operator @ and @@ to round up the
   next integer to a power of 2 or powerof2+1
   Score sorting made much faster
   lineto improved
   Named gens allowed
   Various printing include instrument name if available
   Command option to omit loading a library
   Number of out channels no longer constrained to be number of in
   Many fixes to new parser
   More use of Warnings than Messages (allows for them to be switched  
off)


API:
csoundSetMessageCallback reset if callback set to null

Internal:
usual collection of gratuitous minor changes, layout and comments
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [LAA] gst123-0.1.4

2011-01-26 Thread Niels Mayer 
Here's one more backtrace that's even more interesting. Perhaps a
varargs error: see gst_structure_id_set_valist() ??
...

gnulem-106-~/gst123-git> gdb --args src/gst123 -a alsa=66spdif
http://64.12.61.1:80/stream/1046
GNU gdb (GDB) Fedora (7.0.1-50.fc12)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/npm/gst123-git/src/gst123...done.
(gdb) run
Starting program: /home/npm/gst123-git/src/gst123 -a alsa=66spdif
http://64.12.61.1:80/stream/1046
[Thread debugging using libthread_db enabled]
Detaching after fork from child process 1290.

Playing http://64.12.61.1:80/stream/1046
[New Thread 0x70e0c710 (LWP 1291)]
[New Thread 0x7fffebfff710 (LWP 1292)]
[New Thread 0x7fffe3fff710 (LWP 1293)]
[New Thread 0x7fffe35fe710 (LWP 1294)]
[Thread 0x7fffe35fe710 (LWP 1294) exited]

Title   : All Things Considered  -  5 Artist  :
Album   : Genre   : Eclectic, Alternative, NPR,
Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 180.0 kbit/s


Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 180.0 kbit/s


Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 179.0 kbit/s


Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 169.0 kbit/s


Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 169.0 kbit/s


Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 170.0 kbit/s


Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 170.0 kbit/s


Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 180.0 kbit/s


Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 179.0 kbit/s


Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 169.0 kbit/s


Title   : Art Talk  -  All Things Con Artist  :
Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 169.0 kbit/s


Title   : All Things Considered  -  5 Artist  :
Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 169.0 kbit/s


Title   : Which Way, L.A.?  -  7P-8P  Artist  :
Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 169.0 kbit/s


Title   : Garth Trinidad 89.9FM Hand- Artist  :
Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 169.0 kbit/s

Time: 2:37:38.96
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x70e0c710 (LWP 1291)]
0x00369b27b1eb in gst_structure_set_field (structure=0x7fffec061320,
field=0x70e0b690) at gststructure.c:692
692 if (G_UNLIKELY (f->name == field->name)) {
(gdb) bt full
#0  0x00369b27b1eb in gst_structure_set_field (structure=
0x7fffec061320, field=0x70e0b690) at gststructure.c:692
_g_boolean_var_ = 
f = 0x0
i = 0
len = 1
__PRETTY_FUNCTION__ = "gst_structure_set_field"
#1  0x00369b27d7a4 in gst_structure_id_set_valist (
structure=, fieldname=,
varargs=0x70e0b700) at gststructure.c:603
field = {name = 68, value = {g_type = 24, data = {{v_int = -1,
v_uint = 4294967295, v_long = 4294967295, v_ulong =
4294967295, v_int64 = 4294967295, v_uint64 = 4294967295, v_float =
-nan(0x7f), v_double = 2.1219957904712067e-314, v_pointer =
0x}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 =
0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0
err = 
type = 
__PRETTY_FUNCTION__ = "gst_structure_id_set_valist"
#2  0x00369b27d948 in gst_structure_id_new (
name_quark=, field_quark=)
at gststructure.c:638
s = 
varargs = {{gp_offset = 48, fp_offset = 48, overflow_arg_area =
0x70e0b800, reg_save_area = 0x70e0b720}}
__PRETTY_FUNCTION__ = "gst_structure_id_new"
#3  0x00369b256a5a in gst_message_new_buffering (src=
0x7fffec0180b0 [GstQueue2], percent=3) at gstmessage.c:538
structure = 
__PRETTY_FUNCTION__ = "gst_message_new_buffering"
#4  0x70e2897f in update_buffering (queue=
0x7fffec0180b0 [GstQueue2]) at gstqueue2.c:773
message = 
mode = GST_BUFFERING_STREAM
buffering_left = -1
percent = 
post = 1
__PRETTY_FUNCTION__ = "update_buffering"
#5  0x70e29a37 in gst_queue2_locked_enqueue (queue=
0x7fffec0180b0 [GstQueue2], item=0x646e90) at gstqueue2.c:1389
__PRETTY_FUNCTION__ = "gst_queue2_locked_enqueue"
#6  0x70e2aefd in gst_queue2_chain (pad=,
buffer=0x646e90 [GstBuffer]) at gstqueue2.c:1673
queue = 0x7fffec0180b0 [GstQueue2]
__PRETTY_FUNCTION__ = "gst_queue2_chain"
#7  0x00369b261a05 in gst_pad_chain_data_unchecked (pad=
0x8f1960 [GstPad], is_buffer=1, data=0x646e90) at gstpad.c:4131
chainfunc = 0x70e2a8d0 
caps = 
caps_chan

Re: [LAD] [LAA] gst123-0.1.4

2011-01-26 Thread Niels Mayer 
In the last backtrace I sent, I forgot to install debug symbols on the
included libs, so here's another backtrace from a memory-error core
dump with all the debug symbols available.

After the first listing, there's another listing from a stream that
hung, which seems to be an alternate behavior of gst123 when the
stream isn't causing memory corruption/core dump behavior. In the
"hang" case, you see the time-elapsed counter staying fixed, and the
process just spins; which is a different behavior than if the  stream
were to be interrupted -- which terminates correctly and doesn't
"spin." The latter backtrace is from a SIGINT on the spinning process
but should at least indicate where it was spinning.

Note some signs of corruption -- timestamp=-1 ??: "
"http://64.12.61.1:80/stream/1046"}, playbin = 0x8e02f0 [GstPlayBin2],
  loop = 0x8c4a00, play_position = 1, cols = 77, tags = {
timestamp = -1, title = "", artist = "", album = "", date = "",
comment = "", genre = "", codec = ..."


Starting program: /home/npm/gst123-git/src/gst123 -a alsa=66spdif
http://64.12.61.1:80/stream/1046
[Thread debugging using libthread_db enabled]
Detaching after fork from child process 1290.

Playing http://64.12.61.1:80/stream/1046
[New Thread 0x70e0c710 (LWP 1291)]
[New Thread 0x7fffebfff710 (LWP 1292)]
[New Thread 0x7fffe3fff710 (LWP 1293)]
[New Thread 0x7fffe35fe710 (LWP 1294)]
[Thread 0x7fffe35fe710 (LWP 1294) exited]

Title   : All Things Considered  -  5 Artist  :
Album   : Genre   : Eclectic, Alternative, NPR,
Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 180.0 kbit/s



Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 180.0 kbit/s


Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 179.0 kbit/s


Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 169.0 kbit/s


Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 169.0 kbit/s


Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 170.0 kbit/s


Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 170.0 kbit/s


Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 180.0 kbit/s


Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 179.0 kbit/s


Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 169.0 kbit/s


Title   : Art Talk  -  All Things Con Artist  :
Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 169.0 kbit/s


Title   : All Things Considered  -  5 Artist  :
Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 169.0 kbit/s


Title   : Which Way, L.A.?  -  7P-8P  Artist  :
Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 169.0 kbit/s


Title   : Garth Trinidad 89.9FM Hand- Artist  :
Codec   : MPEG 1 Audio, Layer 3 (MP3) Bitrate : 169.0 kbit/s

Time: 2:37:38.96
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x70e0c710 (LWP 1291)]
0x00369b27b1eb in gst_structure_set_field (structure=0x7fffec061320,
field=0x70e0b690) at gststructure.c:692
692 if (G_UNLIKELY (f->name == field->name)) {
(gdb) bt full
#0  0x00369b27b1eb in gst_structure_set_field (structure=
0x7fffec061320, field=0x70e0b690) at gststructure.c:692
_g_boolean_var_ = 
f = 0x0
i = 0
len = 1
__PRETTY_FUNCTION__ = "gst_structure_set_field"
#1  0x00369b27d7a4 in gst_structure_id_set_valist (
structure=, fieldname=,
varargs=0x70e0b700) at gststructure.c:603
field = {name = 68, value = {g_type = 24, data = {{v_int = -1,
v_uint = 4294967295, v_long = 4294967295, v_ulong =
4294967295, v_int64 = 4294967295, v_uint64 = 4294967295, v_float =
-nan(0x7f), v_double = 2.1219957904712067e-314, v_pointer =
0x}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 =
0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0
err = 
type = 
__PRETTY_FUNCTION__ = "gst_structure_id_set_valist"
#2  0x00369b27d948 in gst_structure_id_new (
name_quark=, field_quark=)
at gststructure.c:638
s = 
varargs = {{gp_offset = 48, fp_offset = 48, overflow_arg_area =
0x70e0b800, reg_save_area = 0x70e0b720}}
__PRETTY_FUNCTION__ = "gst_structure_id_new"
#3  0x00369b256a5a in gst_message_new_buffering (src=
0x7fffec0180b0 [GstQueue2], percent=3) at gstmessage.c:538
structure = 
__PRETTY_FUNCTION__ = "gst_message_new_buffering"
#4  0x70e2897f in update_buffering (queue=
0x7fffec0180b0 [GstQueue2]) at gstqueue2.c:773
message = 
mode = GST_BUFFERING_STREAM
buffering_left = -1
percent = 
post = 1
__PRETTY_FUNCTION__ = "update_buffering"
#5  0x70e29a37 in gst_queue2_locked_enqueue (queue=
0x7fffec0180b0 [GstQueue2], item=0x646e90) at gstqueue2.c:1389
__PRETTY_FUNCTION__ = "gst_queue2_locked_enqueue"
#6  0x70e2aefd i

Re: [LAD] [ANN] IR: version 1.2

2011-01-26 Thread hermann 
Am Mittwoch, den 26.01.2011, 13:29 +0100 schrieb Tom Szilagyi:
> 2011/1/26 Jörn Nettingsmeier :
> >
> > since it's based on zita-convolver: did you also use the multi-threaded
> > partitioned convolution approach from jconvolver?
> 
> Hi Jörn,
> 
> I'm not sure about the mentioned approach, since I'm not familiar with
> the jconvolver source, only zita-convolver (and only from a user
> p.o.v; haven't modified it). So I don't know that this multi-threaded
> approach you mention is something jconvolver actually does, or is it
> just the usual workings of zita-convolver (which I use in a really
> simple manner).

It's zita-convolver who create the multi-threaded partitioned
convolution threads, in that sense jconvolver is a front-end like IR or
like we do in guitarix. 

greats  hermann

> 
> I will look at the jconvolver source to educate myself about said
> approach when I have a bit of free time.
> 
> > if so, how does IR behave in freewheeling mode?
> 
> As usual: it works for me 10 out of 10 times (at least for what I do
> and how I work), but YMMV. I must admit that I don't use freewheeling
> that much, but some test passes with various projects (some simple and
> some big) on two machines, one older single processor and one fairly
> recent quad core (both 64 bit), indicated no problems. Of course this
> means nothing at all in this case.
> 
> >
> > i'm asking because jconvolver is known to have problems with the timing of
> > its non-jack helper threads in freewheeling mode, which has finally bitten
> > me a few days ago (haven't had problems with it before). jconvolver is nice
> > enough to halt the entire graph (at least with tschack), so it's always
> > obvious there was a problem.
> > i just want to make sure that *if* IR fails in freewheeling, it will fail in
> > some obvious way.
> 
> That would be definitely nice but currently missing. I would say that
> if there is a problem with jconvolver, IR most probably also has this
> problem.
> 
> I tend to listen to what I commit, though, so I bounce in realtime.
> 
> Tom
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: version 1.2

2011-01-26 Thread Tom Szilagyi 
2011/1/26 Jörn Nettingsmeier :
>
> since it's based on zita-convolver: did you also use the multi-threaded
> partitioned convolution approach from jconvolver?

Hi Jörn,

I'm not sure about the mentioned approach, since I'm not familiar with
the jconvolver source, only zita-convolver (and only from a user
p.o.v; haven't modified it). So I don't know that this multi-threaded
approach you mention is something jconvolver actually does, or is it
just the usual workings of zita-convolver (which I use in a really
simple manner).

I will look at the jconvolver source to educate myself about said
approach when I have a bit of free time.

> if so, how does IR behave in freewheeling mode?

As usual: it works for me 10 out of 10 times (at least for what I do
and how I work), but YMMV. I must admit that I don't use freewheeling
that much, but some test passes with various projects (some simple and
some big) on two machines, one older single processor and one fairly
recent quad core (both 64 bit), indicated no problems. Of course this
means nothing at all in this case.

>
> i'm asking because jconvolver is known to have problems with the timing of
> its non-jack helper threads in freewheeling mode, which has finally bitten
> me a few days ago (haven't had problems with it before). jconvolver is nice
> enough to halt the entire graph (at least with tschack), so it's always
> obvious there was a problem.
> i just want to make sure that *if* IR fails in freewheeling, it will fail in
> some obvious way.

That would be definitely nice but currently missing. I would say that
if there is a problem with jconvolver, IR most probably also has this
problem.

I tend to listen to what I commit, though, so I bounce in realtime.

Tom
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: version 1.2

2011-01-26 Thread Jörn Nettingsmeier 

On 01/25/2011 05:50 PM, Tom Szilagyi wrote:

Version 1.2 of IR, an LV2 convolution reverb plugin has just been released.

This release is the result of many hours of stress-testing, and corrects some
small but unpleasant problems you may have run into while using an earlier
version. IR 1.2 is intended to be production quality software you can rely on.
Please do upgrade to this version.

Changes:
* fix ir.ttl typo: "doap:license" instead of "doap:licence"
* visual feedback of the progress of resampling operations
* resampling operations are interruptible; you can no longer crash
   the plugin by deleting it while resampling a long impulse file
* correct GTK2 version requirement and check it in the Makefile:
   at least GTK 2.16 is needed

Source code is available from the usual webpage:
http://factorial.hu/plugins/lv2/ir


since it's based on zita-convolver: did you also use the multi-threaded 
partitioned convolution approach from jconvolver? if so, how does IR 
behave in freewheeling mode?


i'm asking because jconvolver is known to have problems with the timing 
of its non-jack helper threads in freewheeling mode, which has finally 
bitten me a few days ago (haven't had problems with it before). 
jconvolver is nice enough to halt the entire graph (at least with 
tschack), so it's always obvious there was a problem.
i just want to make sure that *if* IR fails in freewheeling, it will 
fail in some obvious way.


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev