27 Sep
2014
27 Sep
'14
4:28 p.m.
It's job hunting time, and while I am skeptical that there are very many
paying jobs for Linux audio developers out there, I thought I'd at least
ask on this list. What companies are doing work in the Linux audio
universe?
Or, on the other side, anybody know of interesting
music-instrument/audio companies located in or around NYC (where I live)
who might need Linux folks for their web presence or other online stuff?
Any tips appreciated!
Thanks,
Bill Gribble
27 Sep
27 Sep
4:39 p.m.
On Sat, 2014-09-27 at 10:27 -0400, Bill Gribble wrote:
It's job hunting time, and while I am skeptical
that there are very many
paying jobs for Linux audio developers out there, I thought I'd at least
ask on this list. What companies are doing work in the Linux audio
universe?
Or, on the other side, anybody know of interesting
music-instrument/audio companies located in or around NYC (where I live)
who might need Linux folks for their web presence or other online stuff?
Any tips appreciated!
A lot of consumer audio-video stand alone gear is using Linux, e.g.
television satellite receivers. IMO this market might be more
interesting when searching for a job, than the pro-audio market or
Internet presences are.
Just 2 Cents ;),
Ralf
4:59 p.m.
On Sat, 2014-09-27 at 16:39 +0200, Ralf Mardorf wrote:
On Sat, 2014-09-27 at 10:27 -0400, Bill Gribble
wrote:
Lip-sync is an issue, assumed you should have the abilities to fix it,
you likely would find a job.
It's job hunting time, and while I am
skeptical that there are very many
paying jobs for Linux audio developers out there, I thought I'd at least
ask on this list. What companies are doing work in the Linux audio
universe?
Or, on the other side, anybody know of interesting
music-instrument/audio companies located in or around NYC (where I live)
who might need Linux folks for their web presence or other online stuff?
Any tips appreciated!
A lot of consumer audio-video stand alone gear is using Linux, e.g.
television satellite receivers. IMO this market might be more
interesting when searching for a job, than the pro-audio market or
Internet presences are. 
29 Sep
29 Sep
12:22 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 27.09.2014 16:59, Ralf Mardorf wrote:
Can you elaborate on that? What exactly is the problem? And what kind
of solutions are people looking for?
Flo
A lot of
consumer audio-video stand alone gear is using Linux,
e.g. television satellite receivers. IMO this market might be
more interesting when searching for a job, than the pro-audio
market or Internet presences are.
Lip-sync is an issue, assumed you should have the abilities to fix
it, you likely would find a job.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJUKTL2AAoJEA5f4Coltk8ZViwH/27gHPiFKZVQA4Rid6EA/PA5
wUIxhQhzWNq6UdsJ19FgRTDG2S8w3jNEn4rnXi5AuVAHQbh3lk8xx67FwMW9N5c9
jtLXxul2kAVceUfhZvHYg6TYRT3e5yQfPILXUySouxuR4esw9THsDHOueCuz7wUp
i+Ykcx+69q65blPkN0Gnf/M0t7fyH1WgnRMDAMTKkYPlrv1NtMqNklPO8IVRzgNl
gZcwN54Kmny2pwUH4B3PUeazOZMOoRWYXIi3yncvLpSAZIGPHB6ERlK3PnS4arU6
8R9EiUKzVGkcJ/v4A2iRSnrufMZ2p7rkX+8an95AXyCh1VYEUEoCx4Z3sZZsrZI=
=ilJU
-----END PGP SIGNATURE-----
12:34 p.m.
On Mon, 2014-09-29 at 12:22 +0200, Florian Paul Schmidt wrote:
On 27.09.2014 16:59, Ralf Mardorf wrote:
Can you elaborate on that? What exactly is the problem? And what kind
of solutions are people looking for?
I don't know if the Linux kernels used for audio-video consumer gear are
used for audio and video processing, perhaps they are just used to
provide menus etc., but since the end of the 90s I never experienced the
good audio and video sync we had with German terrestrial analog
television. All analog and digital satellite and digital terrestrial
receivers I've seen didn't provide acceptable sync. Assumed at least
some of those receiver should do the audio and video processing using
Linux too, a smart solution to fix such issues, not by just providing
fixed delays, but by detecting the exact drift and automatically fixing
it, might be from interest for the consumer gear companies. Perhaps,
they wouldn't care about a smart way to fix it, OTOH for colour
correctness at least Germany cared, so we once upon a time got PAL.
A lot of
consumer audio-video stand alone gear is using Linux,
e.g. television satellite receivers. IMO this market might be
more interesting when searching for a job, than the pro-audio
market or Internet presences are.
Lip-sync is an issue, assumed you should have the abilities to fix
it, you likely would find a job.
12:41 p.m.
Le 29 sept. 2014 à 12:34, Ralf Mardorf <ralf.mardorf(a)rocketmail.com> a écrit :
On Mon, 2014-09-29 at 12:22 +0200, Florian Paul
Schmidt wrote:
you did see that ? I'm surprised. Which brand ?
I've worked for two years on the A/V testbenches for sagemcom making a whole lot of
digital satellite receivers and never noticed that.
Until two years ago they used an RT system on STM32 processors. The move to embedded linux
was quite new, maybe introducing this issue.
Raphaël
On 27.09.2014 16:59, Ralf Mardorf wrote:
Can you elaborate on that? What exactly is the problem? And what kind
of solutions are people looking for?
I don't know if the Linux kernels used for audio-video consumer gear are
used for audio and video processing, perhaps they are just used to
provide menus etc., but since the end of the 90s I never experienced the
good audio and video sync we had with German terrestrial analog
television. All analog and digital satellite and digital terrestrial
receivers I've seen didn't provide acceptable sync. Assumed at least
some of those receiver should do the audio and video processing using
Linux too, a smart solution to fix such issues, not by just providing
fixed delays, but by detecting the exact drift and automatically fixing
it, might be from interest for the consumer gear companies. Perhaps,
they wouldn't care about a smart way to fix it, OTOH for colour
correctness at least Germany cared, so we once upon a time got PAL.
A lot of
consumer audio-video stand alone gear is using Linux,
e.g. television satellite receivers. IMO this market might be
more interesting when searching for a job, than the pro-audio
market or Internet presences are.
Lip-sync is an issue, assumed you should have the abilities to fix
it, you likely would find a job.
1:47 p.m.
On Mon, 2014-09-29 at 12:41 +0200, raf wrote:
Le 29 sept. 2014 à 12:34, Ralf Mardorf
<ralf.mardorf(a)rocketmail.com> a écrit :
I don't remember the brands of the satellite receivers I owned
(discounter thingies), but a friend repairs receivers, so I've seen a
lot. Many people in German switched to DVB-T, I can see it on my THOMSON
DTI series 500. It could differ for different broadcasts of the same
station. My claim isn't that the receivers cause the sync issue. I
remember that at least some satellite receivers provided to manually set
a delay, but AFAIK no auto-syncing option does exist (similar as PAL to
ensure colour stability). My DVB-T receiver seems even not to provide to
set a delay manually.
On Mon, 2014-09-29 at 12:22 +0200, Florian Paul
Schmidt wrote:
you did see that ? I'm surprised. Which brand ?
I've worked for two years on the A/V testbenches for sagemcom making a
whole lot of digital satellite receivers and never noticed that.
Until two years ago they used an RT system on STM32 processors. The
move to embedded linux was quite new, maybe introducing this issue. On 27.09.2014 16:59, Ralf Mardorf wrote:
I don't know if the Linux kernels used for audio-video consumer gear are
used for audio and video processing, perhaps they are just used to
provide menus etc., but since the end of the 90s I never experienced the
good audio and video sync we had with German terrestrial analog
television. All analog and digital satellite and digital terrestrial
receivers I've seen didn't provide acceptable sync. Assumed at least
some of those receiver should do the audio and video processing using
Linux too, a smart solution to fix such issues, not by just providing
fixed delays, but by detecting the exact drift and automatically fixing
it, might be from interest for the consumer gear companies. Perhaps,
they wouldn't care about a smart way to fix it, OTOH for colour
correctness at least Germany cared, so we once upon a time got PAL.
> A lot of consumer audio-video stand alone
gear is using Linux,
> e.g. television satellite receivers. IMO this market might be
> more interesting when searching for a job, than the pro-audio
> market or Internet presences are.
Lip-sync is an issue, assumed you should have the abilities to fix
it, you likely would find a job.
Can you elaborate on that? What exactly is the problem? And what kind
of solutions are people looking for?
1:53 p.m.
On Mon, 2014-09-29 at 13:47 +0200, Ralf Mardorf wrote:
On Mon, 2014-09-29 at 12:41 +0200, raf wrote:
And I don't claim that THOMSON does use Linux, perhaps, perhaps not. I
only want to point out that lip-sync is a known issue in Germany and
that lot of consumer gear does use Linux. The lip-sync issue might be
caused by the station or anywhere in the chain from station to receiver.
If somebody would event something, that could automatically fix it, this
perhaps could become the next great invention, after the invention of
PAL.
Le 29 sept. 2014 à 12:34, Ralf Mardorf
<ralf.mardorf(a)rocketmail.com> a écrit :
I don't remember the brands of the satellite receivers I owned
(discounter thingies), but a friend repairs receivers, so I've seen a
lot. Many people in German switched to DVB-T, I can see it on my THOMSON
DTI series 500. It could differ for different broadcasts of the same
station. My claim isn't that the receivers cause the sync issue. I
remember that at least some satellite receivers provided to manually set
a delay, but AFAIK no auto-syncing option does exist (similar as PAL to
ensure colour stability). My DVB-T receiver seems even not to provide to
set a delay manually. On Mon, 2014-09-29 at 12:22 +0200, Florian Paul
Schmidt wrote:
you did see that ? I'm surprised. Which brand ?
I've worked for two years on the A/V testbenches for sagemcom making a
whole lot of digital satellite receivers and never noticed that.
Until two years ago they used an RT system on STM32 processors. The
move to embedded linux was quite new, maybe introducing this issue. On 27.09.2014 16:59, Ralf Mardorf wrote:
>> A lot of consumer audio-video stand alone gear is using Linux,
>> e.g. television satellite receivers. IMO this market might be
>> more interesting when searching for a job, than the pro-audio
>> market or Internet presences are.
>
> Lip-sync is an issue, assumed you should have the abilities to fix
> it, you likely would find a job.
>
Can you elaborate on that? What exactly is the problem? And what kind
of solutions are people looking for?
I don't know if the Linux kernels used for audio-video consumer gear are
used for audio and video processing, perhaps they are just used to
provide menus etc., but since the end of the 90s I never experienced the
good audio and video sync we had with German terrestrial analog
television. All analog and digital satellite and digital terrestrial
receivers I've seen didn't provide acceptable sync. Assumed at least
some of those receiver should do the audio and video processing using
Linux too, a smart solution to fix such issues, not by just providing
fixed delays, but by detecting the exact drift and automatically fixing
it, might be from interest for the consumer gear companies. Perhaps,
they wouldn't care about a smart way to fix it, OTOH for colour
correctness at least Germany cared, so we once upon a time got PAL.
1:58 p.m.
This has become offtopic!
Please change the subject. I am very interested in Linux Audio jobs and
companies but not at all in discussions that got ralfed.
Thank you.
14 Oct
14 Oct
7:22 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 29.09.2014 12:34, Ralf Mardorf wrote:
I don't know if the Linux kernels used for audio-video consumer
gear are used for audio and video processing, perhaps they are just
used to provide menus etc., but since the end of the 90s I never
experienced the good audio and video sync we had with German
terrestrial analog television. All analog and digital satellite and
digital terrestrial receivers I've seen didn't provide acceptable
sync. Assumed at least some of those receiver should do the audio
and video processing using Linux too, a smart solution to fix such
issues, not by just providing fixed delays, but by detecting the
exact drift and automatically fixing it, might be from interest for
the consumer gear companies. Perhaps, they wouldn't care about a
smart way to fix it, OTOH for colour correctness at least Germany
cared, so we once upon a time got PAL.
Sorry for not coming back to you earlier. I would suppose it's just
laziness on the part of the receiver manufacturers. If the receiver
manufacturers were willing to shell out the money to get it done
right, they would have done so. So I don't see any job opportunities
here..
And if it's a problem with the underlying stream specifications or how
the stations broadcast them, then it will probably never get fixed :)
Regards,
Flo
Lip-sync is an issue, assumed you should have the
abilities to
fix it, you likely would find a job.
Can you elaborate on that? What exactly is the problem? And what
kind of solutions are people looking for? -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJUPVu7AAoJEA5f4Coltk8ZC6sH/AvJA2pyp3hGV8kHFlNSmqB+
lB0PzC0k1aq0rPLmvmV1morm2ei40CJF7w1UswnCfjW6t6vmJn1mVdg+omyjoQsn
ylEuFyX4qLV9lUI/Sm6fMbL2ZtuVag+H2cA4Kv9BrUrYDvLjyTcl0MpQqSmzwaQH
k5MeTTds0dE2vDiB9EnakGhbHcBeX+sZSTvHU3STsSNKvd0S0eUW4xOWhUYdkoCi
eVxK/aYBccjtwZwXhv5SBDFuyulZPwoV8PZ9WXeLEI8V+W28N07heT6IweTakBhq
3MVGzeTXMseOxb8AGwcIWD2r6ZsZlbl7/5TcPYwe2314eFQXngWRFkOogy6kn0M=
=iT6x
-----END PGP SIGNATURE-----
3476
days inactive
3493
days old
linux-audio-dev@lists.linuxaudio.org
10 comments
5 participants
participants (5)
-
Bill Gribble -
Florian Paul Schmidt -
Nils -
raf -
Ralf Mardorf