Re: [LAD] So what do you think sucks about Linux audio ?

[Jörn Nettingsmeier]

On 02/05/2013 03:58 PM, Dave Phillips wrote:

Greetings,



I'm not so interested in comments on the commentary, I have my own, but
say what you will about the list. I figure that most denizens of these
lists already have ready replies and responses to these and other
criticisms, many of which have been voiced here previously. What I'm
more interested in is what *you* think is missing most or just plain
wrong about the situation. Please, try to speak your piece without
flames or dissing other developers and/or their work.


[drum roll, the following with at least 15% THD and the distinct sound 
of a 50s ribbon mike after long abuse:]


ask not what free software can do for you, ask what you can do for free 
software!


[enter brass band with some heroic yet totally cheesy hymn arrangement, 
think charles ives stealing frank zappa's reggae horn arrangement of the 
stairway to heaven solo.]




free software, my friends, is a natural resource. complaining about the 
lack of this or that is just about as clever or useful as complaining 
about the utter lack of oil or rare earth metals on your home turf, 
which unjustly prevents you from becoming the next rockefeller.
making linux audio more approachable to people who have not grasped this 
basic fact has no benefits at all, neither to developers nor to users.


personally, i find my days of linux audio evangelism are over. it suits 
my needs better than ever before, and i make very sure that people i 
talk to are made aware of the treasure trove of linux audio tools.
and of course i assume the lotus position and put on my most radiating 
smile when people who have just figured that i'm a sort of computer 
person then start complaining about their problems with operating system 
$FOO and how proprietary tool $BAR is just a millstone around their 
necks. but that's it.
if they need guitar rig or protools or garageband, we can't give it to 
them, so obviously they are better off on other platforms. that is good. 
it's even better than turning them into frustrated converts who then 
keep complaining how they can't run TDM or RTAS plugins or their VSTs 
keep crashing or whatever.


if somebody decides to take the plunge (which also implies some other 
basic skills, such as being able to use email in a constructive manner, 
learning what IRC is, aiming at learning to compile one's own software, 
and so on), i will try to share tricks and help out as best as i can.


but why press-gang perfectly happy users of proprietary software into 
linux, or put up with jerks who think the world has to support their 
personal way of composing? that's just the lamest thing i can imagine.


don't get me wrong, i think it's perfectly ok for non-programmers to try 
and nudge developers gently towards what you think are good ideas. i do 
it myself all the time, but i try to do it 
_from_the_inside_of_a_project. that means i try to make myself a little 
useful, subscribe to the mailing list, learn the software, build from 
the latest dev tree, lose some productive time dealing with crashes and 
try to provide useful feedback. only then do i sound off about what new 
stuff i'd like to see.


anything else is just bikeshedding.


my 200 €.


jörn


--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487

Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT

http://stackingdwarves.net

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

Re: [LAD] simple silence detection tool

[Florian Paul Schmidt]

On 02/10/2013 08:38 AM, Jeremy Hansen wrote:

I'm looking for a simple tool where I can point it at an http audio stream, 
define a number of seconds to detect silence and exit with a non-zero status if 
silence is detected.  It seems like this should be easy but I've been search 
high and low for such a utility and nothing simple exists.  Unfortunately I'm 
not much of a developer, but this doesn't seem like it would be that difficult. 
 Maybe it's harder than I think, hence no tool that I can find.



Probably noone needed this precice functionality yet. I would look for 
options to assemble this from lower level components:


1] A tool that can read from an http stream and write it into a pipe 
(maybe mplayer/mencoder)


2] A tool to convert the stream from the compressed format into a very 
low samplerate simple to parse format that reads from that pipe and 
writes to another.. (mencoder)


3] A small bash script or python or whatever floats your boat program 
that takes the low samplerate, simple to parse output and detects 
silences in it. If the silence is "true" silence, something as simple as 
searching for a long enough string of 0-bytes is enough..


Flo

--
Florian Paul Schmidt
http://fps.io

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

Re: [LAD] simple silence detection tool

[Adrian Knoth]

On Sun, Feb 10, 2013 at 12:39:17PM +0100, Florian Paul Schmidt wrote:


> >I'm looking for a simple tool where I can point it at an http audio
> >stream, define a number of seconds to detect silence and exit with a
> >non-zero status if silence is detected.  It seems like this should be
> >easy but I've been search high and low for such a utility and nothing
> >simple exists.  Unfortunately I'm not much of a developer, but this
> >doesn't seem like it would be that difficult.  Maybe it's harder than
> >I think, hence no tool that I can find.

> Probably noone needed this precice functionality yet.

The radio guys have this stuff to see if their streams are still alive.

Ah, here it is:

http://www.aelius.com/njh/silentjack/

Use any player (mplayer, cvlc, gstreamer) with jackd support to decode
your stream or use the usual anything-to-jackd magic to make your
consumer applications work with jackd.


Something like this:

   $ jackd -d dummy   (won't terminate and will not output anything)

   $ gst-launch uridecodebin uri=http://some.stream/ ! \
audioconvert ! audioresample ! jackaudiosink connect=none

   $ mplayer -ao jack,port=SilentJack http://some.stream/   


> 1] A tool that can read from an http stream and write it into a pipe
> (maybe mplayer/mencoder)

mencoder is dead. mplayer, vlc, gstreamer and co are alive.



Cheers

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver

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

Re: [LAD] [LAU] So what do you think sucks about Linux audio ?

[hermann meyer]

Am 10.02.2013 12:25, schrieb Jörn Nettingsmeier:

On 02/05/2013 03:58 PM, Dave Phillips wrote:

Greetings,



I'm not so interested in comments on the commentary, I have my own, but
say what you will about the list. I figure that most denizens of these
lists already have ready replies and responses to these and other
criticisms, many of which have been voiced here previously. What I'm
more interested in is what *you* think is missing most or just plain
wrong about the situation. Please, try to speak your piece without
flames or dissing other developers and/or their work.


[drum roll, the following with at least 15% THD and the distinct sound 
of a 50s ribbon mike after long abuse:]


ask not what free software can do for you, ask what you can do for 
free software!


[enter brass band with some heroic yet totally cheesy hymn 
arrangement, think charles ives stealing frank zappa's reggae horn 
arrangement of the stairway to heaven solo.]




free software, my friends, is a natural resource. complaining about 
the lack of this or that is just about as clever or useful as 
complaining about the utter lack of oil or rare earth metals on your 
home turf, which unjustly prevents you from becoming the next 
rockefeller.
making linux audio more approachable to people who have not grasped 
this basic fact has no benefits at all, neither to developers nor to 
users.


personally, i find my days of linux audio evangelism are over. it 
suits my needs better than ever before, and i make very sure that 
people i talk to are made aware of the treasure trove of linux audio 
tools.
and of course i assume the lotus position and put on my most radiating 
smile when people who have just figured that i'm a sort of computer 
person then start complaining about their problems with operating 
system $FOO and how proprietary tool $BAR is just a millstone around 
their necks. but that's it.
if they need guitar rig or protools or garageband, we can't give it to 
them, so obviously they are better off on other platforms. that is 
good. it's even better than turning them into frustrated converts who 
then keep complaining how they can't run TDM or RTAS plugins or their 
VSTs keep crashing or whatever.


if somebody decides to take the plunge (which also implies some other 
basic skills, such as being able to use email in a constructive 
manner, learning what IRC is, aiming at learning to compile one's own 
software, and so on), i will try to share tricks and help out as best 
as i can.


but why press-gang perfectly happy users of proprietary software into 
linux, or put up with jerks who think the world has to support their 
personal way of composing? that's just the lamest thing i can imagine.


don't get me wrong, i think it's perfectly ok for non-programmers to 
try and nudge developers gently towards what you think are good ideas. 
i do it myself all the time, but i try to do it 
_from_the_inside_of_a_project. that means i try to make myself a 
little useful, subscribe to the mailing list, learn the software, 
build from the latest dev tree, lose some productive time dealing with 
crashes and try to provide useful feedback. only then do i sound off 
about what new stuff i'd like to see.


anything else is just bikeshedding.


my 200 €.


jörn



+me

Often it sucks me, that, with my limited knowledge of the English 
language, I wasn't able to put things right on the point, like you have 
done it here.

Gladly that others could do, and do it.
Many thanks for this.

hermann

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

Re: [LAD] simple silence detection tool

[Jeremy Hansen]

On Feb 10, 2013, at 4:11 AM, Adrian Knoth  wrote:

> On Sun, Feb 10, 2013 at 12:39:17PM +0100, Florian Paul Schmidt wrote:
> 
> 
>>> I'm looking for a simple tool where I can point it at an http audio
>>> stream, define a number of seconds to detect silence and exit with a
>>> non-zero status if silence is detected.  It seems like this should be
>>> easy but I've been search high and low for such a utility and nothing
>>> simple exists.  Unfortunately I'm not much of a developer, but this
>>> doesn't seem like it would be that difficult.  Maybe it's harder than
>>> I think, hence no tool that I can find.
> 
>> Probably noone needed this precice functionality yet.
> 
> The radio guys have this stuff to see if their streams are still alive.
> 
> Ah, here it is:
> 
>http://www.aelius.com/njh/silentjack/
> 
> Use any player (mplayer, cvlc, gstreamer) with jackd support to decode
> your stream or use the usual anything-to-jackd magic to make your
> consumer applications work with jackd.
> 
> 
> Something like this:
> 
>   $ jackd -d dummy   (won't terminate and will not output anything)
> 
>   $ gst-launch uridecodebin uri=http://some.stream/ ! \
>audioconvert ! audioresample ! jackaudiosink connect=none
> 
>   $ mplayer -ao jack,port=SilentJack http://some.stream/   
> 

I saw this but I was missing all the jack info. I rebuilt mplayer with jack 
support. I started jackd per your example:

JACK tmpdir identified as [/dev/shm]
[JACK] cannot open server
Failed to initialize audio driver 'jack'
Could not open/initialize audio device -> no sound.

Perhaps I'm missing a step?

Thanks

> 
>> 1] A tool that can read from an http stream and write it into a pipe
>> (maybe mplayer/mencoder)
> 
> mencoder is dead. mplayer, vlc, gstreamer and co are alive.
> 
> 
> 
> Cheers
> 
> -- 
> mail: a...@thur.de  http://adi.thur.dePGP/GPG: key via keyserver
> 
> ___
> 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] simple silence detection tool

[Adrian Knoth]

On Sun, Feb 10, 2013 at 05:36:16AM -0800, Jeremy Hansen wrote:

> I saw this but I was missing all the jack info. I rebuilt mplayer with
> jack support. I started jackd per your example:

> JACK tmpdir identified as [/dev/shm]
> [JACK] cannot open server
> Failed to initialize audio driver 'jack'
> Could not open/initialize audio device -> no sound.
> 
> Perhaps I'm missing a step?

Wild guess: You've started jackd as root or under a different userid
than mplayer. You must not.

You can run jack_lsp to verify your jackd is up and running.

If it shows you some ports, mplayer should work, too.

You may also find the "patchage" tool useful, run it after starting
jackd, and you can see and manage all your jackd clients.



HTH

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver

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

Re: [LAD] [LAU] So what do you think sucks about Linux audio ? OP reply.

[Dave Phillips]

Greetings,

I've spent this morning reading through the ~200 replies to the topic. 
IMO the thread has devolved gracefully and I have the information I was 
looking for.


I'll make a fuller reply after I get into my article, but it's clear 
that the most pressing need is for more skilled developers. This is in 
stark contrast to the scene in 2000 - at that time virtually every 
member of LAU/LAD was a developer and/or technically involved user. Few 
of us were "just musicians". Now it looks like the musicians outnumber 
the devs, a not entirely unhappy situation, despite evident problems 
rising from the imbalance.


A great "Thank you!" to everyone who replied. For the most part the 
thread stayed on-topic, and I hope that your time was not wasted. I'll 
notify the lists when the article is published and when it's publicly 
readable (LWN subscribers get first look).


Best,

dp

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

Re: [LAD] simple silence detection tool

[Jeremy Hansen]

On Feb 10, 2013, at 6:09 AM, Adrian Knoth  wrote:

> On Sun, Feb 10, 2013 at 05:36:16AM -0800, Jeremy Hansen wrote:
> 
>> I saw this but I was missing all the jack info. I rebuilt mplayer with
>> jack support. I started jackd per your example:
> 
>> JACK tmpdir identified as [/dev/shm]
>> [JACK] cannot open server
>> Failed to initialize audio driver 'jack'
>> Could not open/initialize audio device -> no sound.
>> 
>> Perhaps I'm missing a step?
> 
> Wild guess: You've started jackd as root or under a different userid
> than mplayer. You must not.
> 

Thanks.  This got further.  

> You can run jack_lsp to verify your jackd is up and running.

I don't see this utility at all.

> 
> If it shows you some ports, mplayer should work, too.
> 
> You may also find the "patchage" tool useful, run it after starting
> jackd, and you can see and manage all your jackd clients.
> 

I don't see patchage either.  Using RPMS from the EPEL.

Here's what I see:

[jeremy@serv ~]$ jackd -d dummy
jackd 0.103.0
Copyright 2001-2005 Paul Davis and others.
jackd 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 compiled with System V SHM support.
loading driver ..
creating dummy driver ... dummy_pcm|48000|1024|21333|2|2
unknown source port in attempted connection [SilentJack]
unknown source port in attempted connection [SilentJack]

[jeremy@serv ~]$ mplayer -ao jack,port=SilentJack 
http://live.skidrowstudios.com:8000/live
MPlayer dev-SVN-r27514-4.1.2 (C) 2000-2008 MPlayer Team
CPU: Intel(R) Xeon(R) CPU   X3220  @ 2.40GHz (Family: 6, Model: 15, 
Stepping: 11)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled with runtime CPU detection.

Playing http://live.skidrowstudios.com:8000/live.
Resolving live.skidrowstudios.com for AF_INET6...
Couldn't resolve name for AF_INET6: live.skidrowstudios.com
Resolving live.skidrowstudios.com for AF_INET...
Connecting to server live.skidrowstudios.com[54.235.147.151]: 8000...
Name   : Skidrow Studios LIVE!
Genre  : News/Talk/Music
Website: http://www.skidrowstudios.com
Public : yes
Bitrate: 64kbit/s
Cache size set to 320 KBytes
Cache fill:  2.50% (8192 bytes)   
ICY Info: StreamTitle='The Weekly Wrap Up - The Weekly Wrap Up – 02/09/2013 – 
episode 50/Drew Marks, Rich Slaton';
Cache fill: 10.00% (32768 bytes)   
Audio only file format detected.
==
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
mpg123: Can't rewind stream by 216 bits!
AUDIO: 22050 Hz, 2 ch, s16le, 64.0 kbit/9.07% (ratio: 8000->88200)
Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
==
JACK tmpdir identified as [/dev/shm]
AO: [jack] 48000Hz 2ch floatle (4 bytes per sample)
Video: no video
Starting playback...
A: 246.0 (04:05.9) of -0.0 (unknown)  0.6% 18%  
  

[jeremy@serv ~]$ silentjack -v -n SilentJack
JACK tmpdir identified as [/dev/shm]
JACK client registered as 'SilentJack'.
Input port isn't connected to anything.
Input port isn't connected to anything.
Input port isn't connected to anything.
Input port isn't connected to anything.
Input port isn't connected to anything.

I tried doing silentjack -c SilentJack, but this didn't work.

[jeremy@serv ~]$ silentjack -c SilentJack
JACK tmpdir identified as [/dev/shm]
JACK client registered as 'silentjack'.
Connecting SilentJack to silentjack:in
connect_jack_port(): failed to jack_connect() ports: -1

Thanks

> 
> 
> HTH
> 
> -- 
> mail: a...@thur.dehttp://adi.thur.de  PGP/GPG: key via keyserver
> 

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

[LAD] Fwd: [LAU] So what do you think sucks about Linux audio ?

[drew Roberts]

Oops, mistakenly replied direct instead of to list. Forwarding.


-- Forwarded message --
From: drew Roberts 
Date: Sun, Feb 10, 2013 at 8:55 AM
Subject: Re: [LAU] So what do you think sucks about Linux audio ?
To: Ralf Mardorf 


On Sun, Feb 10, 2013 at 8:37 AM, Ralf Mardorf
 wrote:
> On Sun, 2013-02-10 at 12:17 +0100, Jörn Nettingsmeier wrote:
>> On 02/10/2013 01:59 AM, gerald.mwa...@gmx.de wrote:
>>
snip
>
> Using Linux, keeping the workflow can become a PITA, just by updating
> the DE ;), there are no updates for a 8 track analog recorder.

So just buy an already setup, tested, and warranted computer from
someone who knows what they are doing. Then, ***do not update it
yourself*** - use it as is just like a dedicated piece of equipment.
Down the road, get that same person who knows what they are doing to
update it for you or build you a new one.

I am not saying that these problems do not exist, and things can get
better for those who don't mind knowing a bit. I am saying thought
that for the person who does not want to know anything, they can avoid
the knowing somewhat if they will take an approach along the lines
mentioned.
>
> IMO the issue is "stand alone" vs "computer".
>
> Regards,
> Ralf


all the best,

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

Re: [LAD] simple silence detection tool

[Adrian Knoth]

On 02/10/2013 04:43 PM, Jeremy Hansen wrote:

>> You can run jack_lsp to verify your jackd is up and running.
> I don't see this utility at all.

It should be part of your jackd installation. Since you seem to be on
RHEL, the package is called j-a-c-k-example-clients or something like
this.


>> You may also find the "patchage" tool useful, run it after starting
>> jackd, and you can see and manage all your jackd clients.
> I don't see patchage either.  Using RPMS from the EPEL.
> 
> Here's what I see:
> 
> [jeremy@serv ~]$ jackd -d dummy
> jackd 0.103.0

This is ancient.

Linux audio is bleeding edge, RHEL is the exact opposite. You may want
to include the CCRMA repository.

Note that you don't necessarily have to update, you're just using it
wrong atm.

> [jeremy@serv ~]$ mplayer -ao jack,port=SilentJack 
> http://live.skidrowstudios.com:8000/live

The port= needs further tweaks. That's up to you to figure out what
to put there.

A proper port name looks like "clientname:portname".

> [jeremy@serv ~]$ silentjack -v -n SilentJack
> JACK tmpdir identified as [/dev/shm]
> JACK client registered as 'SilentJack'.
> Input port isn't connected to anything.
> Input port isn't connected to anything.
> Input port isn't connected to anything.
> Input port isn't connected to anything.
> Input port isn't connected to anything.
> 
> I tried doing silentjack -c SilentJack, but this didn't work.

See, that's why I recommended to use patchage, where you can simply wire
it up graphically.

Alternatives to patchage: qjackctl, shell

Shell: Once you have your example-clients installed, you can use


   $ jack_lsp


to figure out the exact portnames and

   $ jack_connect mplayer:foo  silentjack:input

or however the ports are called.

I guess you want to add "name=mplayer" to mplayer's jack output module
to prevent it from creating a name that changes every time you restart
mplayer.



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

Re: [LAD] simple silence detection tool

[Robin Gareus]

On 02/10/2013 08:38 AM, Jeremy Hansen wrote:
> 
> I'm looking for a simple tool where I can point it at an http audio
> stream, define a number of seconds to detect silence and exit with a
> non-zero status if silence is detected.  It seems like this should be
> easy but I've been search high and low for such a utility and nothing
> simple exists.  Unfortunately I'm not much of a developer, but this
> doesn't seem like it would be that difficult.  Maybe it's harder than
> I think, hence no tool that I can find.

https://github.com/x42/silan may do the job. It prints ranges or silence
in a file or stream (incl. mp3,aac,wma,ogg,m4a,.. decoding and http,
rtmp stream support thanks to libav/ffmpeg). It is used by airtime
(sourcefabric's radio) to highlight silent ranges.

silan -t 0.1 -s -60d "http://mp2.somafm.com:9016"; \
|  grep -quiet "Sound Off" \
&& echo " do something"
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] simple silence detection tool

[Jeremy Hansen]

I actually got it to work!  Thanks for your help.  I installed the jack example 
clients package, which is where the jack_lsp utility is.  When I started 
silentjack like this:

silentjack -c "MPlayer [24538]:out_0" echo "Shit"

as soon as I turned down the levels on the audio source, silentjack did the 
right thing:

[jeremy@serv ~]$ silentjack -c "MPlayer [24538]:out_0" echo "Shit"
JACK tmpdir identified as [/dev/shm]
JACK client registered as 'silentjack'.
Connecting MPlayer [24538]:out_0 to silentjack:in
**SILENCE**
Shit
**SILENCE**
Shit
**SILENCE**
Shit

When I turned it back up, the echo stopped.

I think all I need for a nagios check is for the command to just exit a 
non-zero status to trip nagios.

This is great!  Just saved me $400 on a hardware based silence monitor.  What's 
cool is that since I'm using icecast, I could even have it react to take over 
the icecast mount with alternative audio stream.

-jeremy

On Feb 10, 2013, at 7:43 AM, Jeremy Hansen  wrote:

> 
> On Feb 10, 2013, at 6:09 AM, Adrian Knoth  wrote:
> 
>> On Sun, Feb 10, 2013 at 05:36:16AM -0800, Jeremy Hansen wrote:
>> 
>>> I saw this but I was missing all the jack info. I rebuilt mplayer with
>>> jack support. I started jackd per your example:
>> 
>>> JACK tmpdir identified as [/dev/shm]
>>> [JACK] cannot open server
>>> Failed to initialize audio driver 'jack'
>>> Could not open/initialize audio device -> no sound.
>>> 
>>> Perhaps I'm missing a step?
>> 
>> Wild guess: You've started jackd as root or under a different userid
>> than mplayer. You must not.
>> 
> 
> Thanks.  This got further.  
> 
>> You can run jack_lsp to verify your jackd is up and running.
> 
> I don't see this utility at all.
> 
>> 
>> If it shows you some ports, mplayer should work, too.
>> 
>> You may also find the "patchage" tool useful, run it after starting
>> jackd, and you can see and manage all your jackd clients.
>> 
> 
> I don't see patchage either.  Using RPMS from the EPEL.
> 
> Here's what I see:
> 
> [jeremy@serv ~]$ jackd -d dummy
> jackd 0.103.0
> Copyright 2001-2005 Paul Davis and others.
> jackd 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 compiled with System V SHM support.
> loading driver ..
> creating dummy driver ... dummy_pcm|48000|1024|21333|2|2
> unknown source port in attempted connection [SilentJack]
> unknown source port in attempted connection [SilentJack]
> 
> [jeremy@serv ~]$ mplayer -ao jack,port=SilentJack 
> http://live.skidrowstudios.com:8000/live
> MPlayer dev-SVN-r27514-4.1.2 (C) 2000-2008 MPlayer Team
> CPU: Intel(R) Xeon(R) CPU   X3220  @ 2.40GHz (Family: 6, Model: 15, 
> Stepping: 11)
> CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
> Compiled with runtime CPU detection.
> 
> Playing http://live.skidrowstudios.com:8000/live.
> Resolving live.skidrowstudios.com for AF_INET6...
> Couldn't resolve name for AF_INET6: live.skidrowstudios.com
> Resolving live.skidrowstudios.com for AF_INET...
> Connecting to server live.skidrowstudios.com[54.235.147.151]: 8000...
> Name   : Skidrow Studios LIVE!
> Genre  : News/Talk/Music
> Website: http://www.skidrowstudios.com
> Public : yes
> Bitrate: 64kbit/s
> Cache size set to 320 KBytes
> Cache fill:  2.50% (8192 bytes)   
> ICY Info: StreamTitle='The Weekly Wrap Up - The Weekly Wrap Up – 02/09/2013 – 
> episode 50/Drew Marks, Rich Slaton';
> Cache fill: 10.00% (32768 bytes)   
> Audio only file format detected.
> ==
> Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
> mpg123: Can't rewind stream by 216 bits!
> AUDIO: 22050 Hz, 2 ch, s16le, 64.0 kbit/9.07% (ratio: 8000->88200)
> Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
> ==
> JACK tmpdir identified as [/dev/shm]
> AO: [jack] 48000Hz 2ch floatle (4 bytes per sample)
> Video: no video
> Starting playback...
> A: 246.0 (04:05.9) of -0.0 (unknown)  0.6% 18%
>   
>   
> 
> [jeremy@serv ~]$ silentjack -v -n SilentJack
> JACK tmpdir identified as [/dev/shm]
> JACK client registered as 'SilentJack'.
> Input port isn't connected to anything.
> Input port isn't connected to anything.
> Input port isn't connected to anything.
> Input port isn't connected to anything.
> Input port isn't connected to anything.
> 
> I tried doing silentjack -c SilentJack, but this didn't work.
> 
> [jeremy@serv ~]$ silentjack -c SilentJack
> JACK tmpdir identified as [/dev/shm]
> JACK client registered as 'silentjack'.
> Connecting SilentJack to silentjack:in
> connect_jack_port(): failed to jack_connect() ports: -1
> 
> Thanks
> 
>> 
>> 
>> HTH
>> 
>> -- 
>> mail: a...@thur.de   http://adi.thur.de  PGP/GPG: key via keyserver
>> 
> 

Re: [LAD] [LAU] So what do you think sucks about Linux audio ? OP reply.

[Robin Gareus]

On 02/10/2013 03:43 PM, Dave Phillips wrote:
> Greetings,

Hi Dave,

> I've spent this morning reading through the ~200 replies to the topic.
> IMO the thread has devolved gracefully and I have the information I was
> looking for.

I've been waiting for that to say: I can find nothing that sucks about
Linux Audio ('xept maybe ~200 w[h]ining users :))

Looking forward to your article,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] simple silence detection tool

[Jeremy Hansen]

Thanks. This looks good too!!

-jeremy

On Feb 10, 2013, at 8:16 AM, Robin Gareus  wrote:

> On 02/10/2013 08:38 AM, Jeremy Hansen wrote:
>> 
>> I'm looking for a simple tool where I can point it at an http audio
>> stream, define a number of seconds to detect silence and exit with a
>> non-zero status if silence is detected.  It seems like this should be
>> easy but I've been search high and low for such a utility and nothing
>> simple exists.  Unfortunately I'm not much of a developer, but this
>> doesn't seem like it would be that difficult.  Maybe it's harder than
>> I think, hence no tool that I can find.
> 
> https://github.com/x42/silan may do the job. It prints ranges or silence
> in a file or stream (incl. mp3,aac,wma,ogg,m4a,.. decoding and http,
> rtmp stream support thanks to libav/ffmpeg). It is used by airtime
> (sourcefabric's radio) to highlight silent ranges.
> 
> silan -t 0.1 -s -60d "http://mp2.somafm.com:9016"; \
> |  grep -quiet "Sound Off" \
> && echo " do something"
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [LAU] So what do you think sucks about Linux audio ?

[Kjetil Matheussen]

On 07.02.2013 21:21, Kjetil Matheussen wrote:

William Light:
it's interesting to me that free (source and/or beer) music software 
on
OSX and windows has come further than it has on Linux. off the top 
of

my head:

http://psycle.pastnotecut.org/portal.php
http://www.buzzmachines.com/


I'm very interested in knowing what you're missing from Psycle and
Buzzmachines
that Radium doesn't have...


And what about Beast? To me it seems like Beast outnumber the number of 
features

of psycle and buzz?


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

Re: [LAD] simple silence detection tool

[Jeremy Hansen]

On Feb 10, 2013, at 8:16 AM, Robin Gareus  wrote:

> On 02/10/2013 08:38 AM, Jeremy Hansen wrote:
>> 
>> I'm looking for a simple tool where I can point it at an http audio
>> stream, define a number of seconds to detect silence and exit with a
>> non-zero status if silence is detected.  It seems like this should be
>> easy but I've been search high and low for such a utility and nothing
>> simple exists.  Unfortunately I'm not much of a developer, but this
>> doesn't seem like it would be that difficult.  Maybe it's harder than
>> I think, hence no tool that I can find.
> 
> https://github.com/x42/silan may do the job. It prints ranges or silence
> in a file or stream (incl. mp3,aac,wma,ogg,m4a,.. decoding and http,
> rtmp stream support thanks to libav/ffmpeg). It is used by airtime
> (sourcefabric's radio) to highlight silent ranges.
> 
> silan -t 0.1 -s -60d "http://mp2.somafm.com:9016"; \
> |  grep -quiet "Sound Off" \
> && echo " do something"

This is strange.  This works, but I'm unable to grep the output and I'm not 
sure why.  If I pipe to grep, I get nothing.  I tried redirecting stderr to 
stdout and doesn't seem to work.

[jeremy@serv src]$ ./silan -t 2.0 -s -40d 
"http://live.skidrowstudios.com:8000/live";
Info: signal threshold: 0.01 ^= -40.000dBFS
0.069569 Sound On
15.814150 Sound Off

Doing the same test:

[jeremy@serv src]$ ./silan -t 2.0 -s -40d 
"http://live.skidrowstudios.com:8000/live"; | grep "Sound Off"
Info: signal threshold: 0.01 ^= -40.000dBFS


I get nothing.

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

[LAD] C/gtk3/cairo meter widget

[Patrick Shirkey]

Hi,

Before I spend any time to rewrite the gtkmeter.c/h  widget for JAMin to
gtk3/cairo does anyone have one already finished?

Needs to be in C.



--
Patrick Shirkey
Boost Hardware Ltd
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [LAU] So what do you think sucks about Linux audio ? OP reply.

[Charles Z Henry]

On Sun, Feb 10, 2013 at 8:43 AM, Dave Phillips wrote:

> Greetings,
>
> I've spent this morning reading through the ~200 replies to the topic. IMO
> the thread has devolved gracefully and I have the information I was looking
> for.
>
> I'll make a fuller reply after I get into my article, but it's clear that
> the most pressing need is for more skilled developers. This is in stark
> contrast to the scene in 2000 - at that time virtually every member of
> LAU/LAD was a developer and/or technically involved user. Few of us were
> "just musicians". Now it looks like the musicians outnumber the devs, a not
> entirely unhappy situation, despite evident problems rising from the
> imbalance.
>

It would be great if we could get more students involved in linux audio.  8
years ago, I picked up linux in order to program some DSP audio code that I
was thinking about.  It really lowered the barrier of entry into audio
programming.  I think more engineering students could get involved, knowing
some of the things you can do with linux.

My university didn't have an audio program--there were maybe just a few
engineers I knew that were strongly inclined to work on audio or
acoustics.  There is a lack of collaboration between engineering and
art/music students here and very little direction from professors
concerning art and technology--but I see some of that beginning to change.

I think that linux is much more well known and it's easier than ever to get
started.  So--might I suggest to do something more for student outreach?
What do you think would make a difference?

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

Re: [LAD] [LAU] So what do you think sucks about Linux audio ?

[gerald.mwangi]

Auto mode for JACK latency is a good idea. I have another proposition: a dedicated graphical front-end for jack session. It could help users setup their workflow , by providing a list of all the jack aware programs installed, categorized by type (sampler, daw, synth). The program should aid in setting up a project , eg firing up ardour with several tracks, firing up synths (lv2 instruments/hosts incl) with presets selectable from the front-end with a preview sound. The front-end could trigger the synth in question with a midi note when selecting a preset. Lv2 plugins, that is pure audio effects, could also listed with the ability to directly send a signal from the audio interface through the selected plugin to quickly hear what it does. One could then associate the selected plugin with, say a track in ardour, and another plugin with a track in hydrogen or so. This would just be for setting up a project. The fine tuning comes later. Such a front-end could give the linux audio ecosystem as a whole a face, just like qjackctl gives JACK a face, and it does not degrade the quality of the ecosystem. Now of course , one can't expose options of all programs in the session-front-end but just the most important ones to quickly set up the project. You may think, why not just create templates, scripts so on? Well my personal subjective answer: my musical projects vary . I simply can't create templates and scripts because the configuration changes immensely from song to song. So the proposed front-end should allow a quick start into the project so that one could rapidly record an idea.This front-end could also list audio programs, plugins which are currently not installed, so that they are discoverable within one central place, much like an app-store or specialized repo (it could be connected to popular linux audio repos, e.g kxstudio).As a developer in computer vision (I'm doing my PhD developing largely on ubuntu) I am aware technical nitty gritty detail problems (realtime video has a lot in common with realtime audio), but here I'm trying to portray a bigger vision/picture. I've ditched windows years ago, and I have never owned an apple product. But I strongly recommend to learn from the two, to cleanly analyze the good and bad aspects of propriety audio software. Then cherry-pick the good aspects. This can only benefit open-source in general. And to make it clear: it is not my intention to grow the userbase at any cost. I rather want enhance the user experience quality for us current users, devs. You heard it: devs too;-) but in a manner that people can opt in to do things the way they want (no one would have to use the proposed front-end) .I can go further: such a front-end only makes sense if jack-session support is made mandatory, which I've suggested before and earned a storm of negative replies. So let the storm come ;-)Cheers,Gerald-- Sent from my HP TouchPadOn 10.02.2013 17:58, Dan MacDonald  wrote: Hi Ralf!On Sun, Feb 10, 2013 at 12:49 PM, Ralf Mardorf  wrote:
On Sun, 2013-02-10 at 09:59 +, Dan MacDonald wrote:
> * JACK needs to become more plug-and-play. I think its a shame it
> still offers no way to auto-detect optimal settings on any given setup
> and instead the user has to find out what options to tweak then find
> the best settings through trial and error.

How should it be done to auto-detect the best settings? IMO it's
impossible.Surely its possible to get an optimized JACK setup working better than it does currently?I'm not advocating JACK lose any of its options but what I'm thinking is something like this. Lets call the way JACK gets started at present the manual mode and I want to see an auto ('low latency scanner') mode added. On first run, auto-mode would do something equivalent to running a stripped down ecasound that would run a series of tests to determine the best settings (for tracking) that your setup can currently achieve without xruns. It would likely be up to the user to re-run the auto tests when they change hardware unless auto mode scans for that too. Exactly what the test would comprise of I'm not sure but maybe something like simulating a tracking a few tracks w/ plugins added to each. JACK has a dummy audio device so I'm presuming here that it could simulate recording sound too else maybe this is impossible.

>
> * JACK can still fail to start and just leave the user with some
> pretty cryptic errors as to why it failed.

I experienced this very seldom, but it's true, I at least remember one
very strange example on jack devel mailing list a while ago. The output
lead into a completely wrong direction.

> * JACK can't hot swap audio devices and so if the user wants this
> feature they have to integrate PA with JACK which sadly still isn't
> straightforward under many popular distros and then the user has to
> learn about how ALSA, PA and JACK interact.

Are there many cases when users need to switch the audio device?I switch audio device several t

Re: [LAD] [LAU] So what do you think sucks about Linux audio ?

[Paul Davis]

On Sun, Feb 10, 2013 at 5:05 PM,  wrote:

> Auto mode for JACK latency is a good idea.
>  I have another proposition: a dedicated graphical front-end for jack
> session. It could help users setup their workflow , by providing a list of
> all the jack aware programs installed, categorized by type (sampler, daw,
> synth). The program should aid in setting up a project , eg firing up
> ardour with several tracks, firing up synths (lv2 instruments/hosts incl)
> with presets selectable from the front-end with a preview sound. The
> front-end could trigger the synth in question with a midi note when
> selecting a preset. Lv2 plugins, that is pure audio effects, could also
> listed with the ability to directly send a signal from the audio interface
> through the selected plugin to quickly hear what it does. One could then
> associate the selected plugin with, say a track in ardour, and another
> plugin with a track in hydrogen or so.
>

what you are describing is basically the "monolithic app" experience (from
a user perspective) but created using a set of independent applications and
processes.

speaking personally, i think there are better things to do with our time.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [LAU] So what do you think sucks about Linux audio ?

[gerald.mwangi]

Correction:"Now of course , one can't expose options of all programs in the session-front-end but just the most important ones to quickly set up the project. '"I ment: one can't expose all options of each program, but just the most important options of each program to quickly set up the project.Sorry,Gerald-- Sent from my HP TouchPadOn 10.02.2013 23:05, gerald.mwa...@gmx.de  wrote: Auto mode for JACK latency is a good idea. I have another proposition: a dedicated graphical front-end for jack session. It could help users setup their workflow , by providing a list of all the jack aware programs installed, categorized by type (sampler, daw, synth). The program should aid in setting up a project , eg firing up ardour with several tracks, firing up synths (lv2 instruments/hosts incl) with presets selectable from the front-end with a preview sound. The front-end could trigger the synth in question with a midi note when selecting a preset. Lv2 plugins, that is pure audio effects, could also listed with the ability to directly send a signal from the audio interface through the selected plugin to quickly hear what it does. One could then associate the selected plugin with, say a track in ardour, and another plugin with a track in hydrogen or so. This would just be for setting up a project. The fine tuning comes later. Such a front-end could give the linux audio ecosystem as a whole a face, just like qjackctl gives JACK a face, and it does not degrade the quality of the ecosystem. Now of course , one can't expose options of all programs in the session-front-end but just the most important ones to quickly set up the project. You may think, why not just create templates, scripts so on? Well my personal subjective answer: my musical projects vary . I simply can't create templates and scripts because the configuration changes immensely from song to song. So the proposed front-end should allow a quick start into the project so that one could rapidly record an idea.This front-end could also list audio programs, plugins which are currently not installed, so that they are discoverable within one central place, much like an app-store or specialized repo (it could be connected to popular linux audio repos, e.g kxstudio).As a developer in computer vision (I'm doing my PhD developing largely on ubuntu) I am aware technical nitty gritty detail problems (realtime video has a lot in common with realtime audio), but here I'm trying to portray a bigger vision/picture. I've ditched windows years ago, and I have never owned an apple product. But I strongly recommend to learn from the two, to cleanly analyze the good and bad aspects of propriety audio software. Then cherry-pick the good aspects. This can only benefit open-source in general. And to make it clear: it is not my intention to grow the userbase at any cost. I rather want enhance the user experience quality for us current users, devs. You heard it: devs too;-) but in a manner that people can opt in to do things the way they want (no one would have to use the proposed front-end) .I can go further: such a front-end only makes sense if jack-session support is made mandatory, which I've suggested before and earned a storm of negative replies. So let the storm come ;-)Cheers,Gerald-- Sent from my HP TouchPadOn 10.02.2013 17:58, Dan MacDonald  wrote: Hi Ralf!On Sun, Feb 10, 2013 at 12:49 PM, Ralf Mardorf  wrote:
On Sun, 2013-02-10 at 09:59 +, Dan MacDonald wrote:
> * JACK needs to become more plug-and-play. I think its a shame it
> still offers no way to auto-detect optimal settings on any given setup
> and instead the user has to find out what options to tweak then find
> the best settings through trial and error.

How should it be done to auto-detect the best settings? IMO it's
impossible.Surely its possible to get an optimized JACK setup working better than it does currently?I'm not advocating JACK lose any of its options but what I'm thinking is something like this. Lets call the way JACK gets started at present the manual mode and I want to see an auto ('low latency scanner') mode added. On first run, auto-mode would do something equivalent to running a stripped down ecasound that would run a series of tests to determine the best settings (for tracking) that your setup can currently achieve without xruns. It would likely be up to the user to re-run the auto tests when they change hardware unless auto mode scans for that too. Exactly what the test would comprise of I'm not sure but maybe something like simulating a tracking a few tracks w/ plugins added to each. JACK has a dummy audio device so I'm presuming here that it could simulate recording sound too else maybe this is impossible.

>
> * JACK can still fail to start and just leave the user with some
> pretty cryptic errors as to why it failed.

I experienced this very seldom, but it's true, I at least remember one
very strange example on jack devel mailing list a while ago. The output
lead i

Re: [LAD] C/gtk3/cairo meter widget

[Tristan Matthews]

2013/2/10 Patrick Shirkey 

> Hi,
>
> Before I spend any time to rewrite the gtkmeter.c/h  widget for JAMin to
> gtk3/cairo does anyone have one already finished?
>
> Needs to be in C.
>

Therè's this one:
https://github.com/sat-metalab/scenic/blob/master/src/vumeter/vumeter.cpp
https://github.com/sat-metalab/scenic/blob/master/src/include/vumeter.h

It has only a few c++isms and could easily be purely in C.

Best,
Tristan


>
>
> --
> Patrick Shirkey
> Boost Hardware Ltd
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>



-- 
Tristan Matthews
web: http://tristanswork.blogspot.com
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [LAU] So what do you think sucks about Linux audio ?

[gerald.mwangi]

Hi-- Sent from my HP TouchPadOn 10.02.2013 23:30, Paul Davis  wrote: On Sun, Feb 10, 2013 at 5:05 PM,   wrote:
Auto mode for JACK latency is a good idea. I have another proposition: a dedicated graphical front-end for jack session. It could help users setup their workflow , by providing a list of all the jack aware programs installed, categorized by type (sampler, daw, synth). The program should aid in setting up a project , eg firing up ardour with several tracks, firing up synths (lv2 instruments/hosts incl) with presets selectable from the front-end with a preview sound. The front-end could trigger the synth in question with a midi note when selecting a preset. Lv2 plugins, that is pure audio effects, could also listed with the ability to directly send a signal from the audio interface through the selected plugin to quickly hear what it does. One could then associate the selected plugin with, say a track in ardour, and another plugin with a track in hydrogen or so. 
what you are describing is basically the "monolithic app" experience (from a user perspective) but created using a set of independent applications and processes.speaking personally, i think there are better things to do with our time.
 Well just for the initialization of the project. The diversity experience of the multiple programs , ecosystem shall still be preservedGerald
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [LAU] So what do you think sucks about Linux audio ?

[Paul Davis]

On Sun, Feb 10, 2013 at 5:48 PM,  wrote:

> Hi
>
>
>
>
> -- Sent from my HP TouchPad
> --
> On 10.02.2013 23:30, Paul Davis  wrote:
>
>
> On Sun, Feb 10, 2013 at 5:05 PM,  wrote:
>
>> Auto mode for JACK latency is a good idea.
>>  I have another proposition: a dedicated graphical front-end for jack
>> session. It could help users setup their workflow , by providing a list of
>> all the jack aware programs installed, categorized by type (sampler, daw,
>> synth). The program should aid in setting up a project , eg firing up
>> ardour with several tracks, firing up synths (lv2 instruments/hosts incl)
>> with presets selectable from the front-end with a preview sound. The
>> front-end could trigger the synth in question with a midi note when
>> selecting a preset. Lv2 plugins, that is pure audio effects, could also
>> listed with the ability to directly send a signal from the audio interface
>> through the selected plugin to quickly hear what it does. One could then
>> associate the selected plugin with, say a track in ardour, and another
>> plugin with a track in hydrogen or so.
>>
>
> what you are describing is basically the "monolithic app" experience (from
> a user perspective) but created using a set of independent applications and
> processes.
>
> speaking personally, i think there are better things to do with our time.
>
>
> Well just for the initialization of the project. The diversity experience
> of the multiple programs , ecosystem shall still be preserved
>

(1) your HTTP-only email confuses even gmail, and is probably inappropriate
for a technically oriented mailing list like this one.

(2) i'm not really that interested in preserving the "diversity
experience". i think it is much more valuable for developers, who get to
work on their own custom, standalone apps rather than being forced into a
framework as happens with plugin developers. there are a LOT of "linux
audio apps" that would be much more useful as plugins than they are as
standalone JACK clients. but this is only helpful for users, and puts
limitations on developers. look around you to see the result 
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [LAU] So what do you think sucks about Linux audio ?

[Adrian Knoth]

On Sun, Feb 10, 2013 at 11:48:26PM +0100, gerald.mwa...@gmx.de wrote:

> Hi
> 
> 
> 
> -- Sent from my HP TouchPad

This is the third visually offensive e-mail within ten minutes or so.

Could you please stop cross-posting with your totally misconfigured
e-mail client to technical mailinglists?

Come back when you've found the button that leads to a proper plain-text
part in your multipart/alternative mails, or even better, no HTML at
all.


Thanks.

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver

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

Re: [LAD] [LAU] So what do you think sucks about Linux audio ? OP reply.

[Charles Z Henry]

On Sun, Feb 10, 2013 at 3:56 PM, Alexandre Prokoudine <
alexandre.prokoud...@gmail.com> wrote:

> On Mon, Feb 11, 2013 at 1:52 AM, Charles Z Henry wrote:
>
> > I think that linux is much more well known and it's easier than ever to
> get
> > started.  So--might I suggest to do something more for student outreach?
> > What do you think would make a difference?
>
> Off-top of my head, try to get involved with Google Summer of Code.
>

> The graphics folks are traditionally well represented there: Blender,
> GIMP, Krita, Inkscape, Scribus, OpenCV et al. Less so for video, and
> even less for audio.
>
> Alexandre Prokoudine


How about sponsoring good ol fashioned senior projects?  Big and visible
events like Google Summer of Code will be good for some students who want a
summer project on their resumes, but there's a comparatively larger number
of students who need to do a senior project every year.  Likewise the art
and music students need to create some kind of senior year portfolio or
recital.

I'm sure many of you in academics can (and do) encourage your students to
work with Linux.  We may not need funding like GSOC, just some way to get
more recognition of using linux as a platform for academic projects.

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

Re: [LAD] [LAU] So what do you think sucks about Linux audio ?

[josef . jurek]

Mr. Wang; please do not post HTML to the list.  Thanks.

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

Re: [LAD] C/gtk3/cairo meter widget

[Patrick Shirkey]

On Mon, February 11, 2013 9:47 am, Tristan Matthews wrote:
> 2013/2/10 Patrick Shirkey 
>
>> Hi,
>>
>> Before I spend any time to rewrite the gtkmeter.c/h  widget for JAMin to
>> gtk3/cairo does anyone have one already finished?
>>
>> Needs to be in C.
>>
>
> Therè's this one:
> https://github.com/sat-metalab/scenic/blob/master/src/vumeter/vumeter.cpp
> https://github.com/sat-metalab/scenic/blob/master/src/include/vumeter.h
>
> It has only a few c++isms and could easily be purely in C.
>

Thanks. It does look useful. Seems to be written for gtk2 though. Have you
compiled it with gtk3?



--
Patrick Shirkey
Boost Hardware Ltd
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] C/gtk3/cairo meter widget

[Paul Davis]

On Sun, Feb 10, 2013 at 11:16 PM, Patrick Shirkey <
pshir...@boosthardware.com> wrote:

>
> On Mon, February 11, 2013 9:47 am, Tristan Matthews wrote:
> > 2013/2/10 Patrick Shirkey 
>
> > Therè's this one:
> >
> https://github.com/sat-metalab/scenic/blob/master/src/vumeter/vumeter.cpp
> > https://github.com/sat-metalab/scenic/blob/master/src/include/vumeter.h
> >
> > It has only a few c++isms and could easily be purely in C.
> >
>
> Thanks. It does look useful. Seems to be written for gtk2 though. Have you
> compiled it with gtk3?
>

at the very least, it would need a draw() method rather than an expose()
method.

plus, if i read it correctly it also redraws its entire self (subject to
cairo clipping) on every expose.

contrast with the the fastmeter in ardour3's libs/gtkmm2ext which draws
only the changed pixels per expose.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] C/gtk3/cairo meter widget

[Patrick Shirkey]

On Mon, February 11, 2013 3:21 pm, Paul Davis wrote:
> On Sun, Feb 10, 2013 at 11:16 PM, Patrick Shirkey <
> pshir...@boosthardware.com> wrote:
>
>>
>> On Mon, February 11, 2013 9:47 am, Tristan Matthews wrote:
>> > 2013/2/10 Patrick Shirkey 
>>
>> > Therè's this one:
>> >
>> https://github.com/sat-metalab/scenic/blob/master/src/vumeter/vumeter.cpp
>> > https://github.com/sat-metalab/scenic/blob/master/src/include/vumeter.h
>> >
>> > It has only a few c++isms and could easily be purely in C.
>> >
>>
>> Thanks. It does look useful. Seems to be written for gtk2 though. Have
>> you
>> compiled it with gtk3?
>>
>
> at the very least, it would need a draw() method rather than an expose()
> method.
>
> plus, if i read it correctly it also redraws its entire self (subject to
> cairo clipping) on every expose.
>
> contrast with the the fastmeter in ardour3's libs/gtkmm2ext which draws
> only the changed pixels per expose.
>

I would prefer to use that but it's in pure C++ as well as GTK2 so I have
to convert it to c and gtk3 :-(





--
Patrick Shirkey
Boost Hardware Ltd
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev