On Wed, 2005-09-28 at 17:32 +0400, Dmitry Baikov wrote:
>
> yes, its much better: vastly higher bandwidth, much faster bus
> clock.
>
> Theoretical(!) numbers are: FW-400 = 400MBits/s, USB2.0 = 480 MBits/s
thats not a very fair comparison. USB2.0 is the "new USB", FW800 is the
"new FW" :) but FW is also a better protocol, which means its easier to
get close the theoretical maximum than it is with USB.
> >From reading RME mailing lists, I know there were many problems with
> Ricoh controllers (on PCI bursts). And everybody recommends TI. But
> most notebooks to choose from have Ricoh controllers. Do you know if
i have ENE controllers in my two HP laptops, as do a couple of other
people on LAD. there *were* problems with these in the 2.4 kernel
series, but they were fixable from user-space *and* are gone in 2.6
(AFAICT).
if you were in the US, i could offer you the best prices on RME gear
(i'm a dealer), but with a european location, thats not likely.
--p
On 9/28/05, *Paul Davis* <paul(a)linuxaudiosystems.com
<mailto:paul@linuxaudiosystems.com>> wrote:
> Is it possible in practice? And for what number of channels? Also,
is FW
> much better than USB2 and why?
yes, its much better: vastly higher bandwidth, much faster bus clock.
Theoretical(!) numbers are: FW-400 = 400MBits/s, USB2.0 = 480 MBits/s
> As for RME Multiface
i'm not sure that its that hard anymore. kernel 2.6 seemed to have fixes
...
--p
As I see, you insist on RME :) Reasonable choice. More expensive, but
bullet-proof.
From reading RME mailing lists, I know there were many problems with
Ricoh controllers (on PCI bursts). And everybody recommends TI. But most
notebooks to choose from have Ricoh controllers. Do you know if these
problems were solved? According to the list everybody went for Fireface
now, so there's no feedback on modern cardbus setups.
And even less on linux setups.
Questions about FA-101 still remain :)
More opinions / experiences are welcome :)
Thank you.
Dmitry.
Hi all!
I've just recently installed the latest release of linuxsampler (0.3.3?) and
I've got a problem. I only use telnet to access LS. If I want to shut the
sampler down (really quit the server), it tells me something like:
Stopping diskthread...
There it just hangs eternally. I have to kill it. It doesn't stop my work
and playing, but it is nasty and I suppose not the way it is expected to be.
Anyone the same problem, fixes?
Kindest regards
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net - the Linux TextBased Studio guide
Slat Sounds Like A Theremin
Slat 0.4b is up now. It no longer requires ClanLib and the images get
installed properly with make install.
The "b for beta" is there because I've had to leave out the extra
cursor - the one that shows the rotating point.
I'm pretty new to X/imlib programming, and I've run into problems
using imlib_paste_image.
More detail is at
http://blog.dis-dot-dat.net/2005/09/slat-without-clanlib-kde-without.html
There's a commented line that kind of puts the cursor back, but it
behaves strangely.
Everything works without it, so Slat should be perfectly usable.
If anyone has a clue about this, or can spare a few minutes to see if
the same thing happens to them with the extra line in place, I'd be
grateful.
James
--
"I'd crawl over an acre of 'Visual This++' and 'Integrated Development
That' to get to gcc, Emacs, and gdb. Thank you."
(By Vance Petree, Virginia Power)
Anyone have a good suggestion for a tutorial for making accurate
high-resolution high-priority clocks in C? I found some tutorials but
they were kinda old, so wondered if they might be out of date as to how
far real-time scheduling has come on linux. I want to be able to wake up
a pthread very accurately.
Thanks
Iain
I would like to build an application to assist in setting the "Beat" of
a pendulum type clock. This is a tool used by a clock repair person to
set a clock to keep accurate time. It is basically a low frequency
oscilloscope with some specialized functionality.
A microphone is placed inside the clock case and attached to the mic
input of the sound card. I want to have a display of the resulting tick
and tock waveforms. There are two primary functions that are needed to
accurately set a clock's beat.
One is to be able to compare the tick waveform to the tock waveform. A
clock that is off balance and hence off beat will have a difference in
the sound of the tick and the tock. Tick being the pendulum swinging in
one direction vs the tock being the opposite direction swing.
The other function is to measure the time between the tick and the next
tick or full cycle of the pendulum swing. For instance, a lot of
pendulum clocks are set to have a pendulum cycle time of exactly one
second. Measuring this to say, hundredths of a second allows for
accurate adjustment of the clock.
I am looking for pointers to libraries and sample code that might help
me get started with this project. Once completed, it would be released
as an Open-Source project for use by any clock repairer that wants it.
I have not seen any open-source projects of this type and the commercial
units that perform this function cost several hundred dollars.
Helo all,
(1) I'm new to jack (but a competent programmer). It appears that the
cvs repository is missing the top-level configuration file. Following
the instructions from the download page, I do a clean cvs checkout on
a Linux machine, cd to the jack directory, and execute
./autogen.sh
This fails saying
/usr/bin/m4: configure.in: No such file or directory
configure.ac: 218: required file `config/ltmain.sh' not found
Am I missing something?
(2) My actual interest is in looking into the jack-udp protocol, and
I tried getting this all to work on a Mac a few days ago and actually
got much further, but it looks like file recv.c has problems since it
doesn't appear to include any definition if the jackudp_t data type
that it tries to declare in the first line of code; i.e., I get,
/Users/stp/Code/jack/jack.udp/recv.c:14: error: 'jackudp_t'
undeclared (first use in this function)
Does jack.udp work in general?
Is there any documentation of the actual protocol used?
Has anyone thought of using TCP instead of UDP?
(3) I know that there's a binary distribution of the Mac OSX release,
and have it installed; does anyone know where there's a source
distribution?
stp
...any assistance greatly appreciated...
--
Stephen Travis Pope -- http://create.ucsb.edu/~stp
Center for Research in Electronic Art Technology, University of
California, Santa Barbara
Really—I don't know what the meaning or purpose of life is.
But it looks exactly as if something were meant by it. — C.
G. Jung
Hi,
On Sunday 25 Sep 2005 05:43, Stephen Travis Pope wrote:
> Netjack sounds interesting, but the SourceForge site has no code and
> no forum postings.
> Perhaps this is a case of starting a project by claiming the spot on
> SourceForge...
The code is there, but it's only in cvs, there are unfortunately no releases
made on that site yet (says a little about the lack of maturity).
As for the technical merits I see that the discussion has been more about the
transport mechanism and this project hasn't really touched on that subject
yet. To keep it simple the data is sent via udp with floats directly.
For lowlatency, CPU-hungry, work the interesting bit is that there is a master
jack-server that drive all slave jack-servers, thus working around the sync
issues.
A drawback of this is that its only (easily) allowed to connect an actual
soundcard to the master jack-server, the others are best suited for various
processing tasks (Outboard effects, softsynths).
Regards,
Robert
>
> stp
>
> --
> Stephen Travis Pope -- http://create.ucsb.edu/~stp
> Center for Research in Electronic Art Technology, University of
> California, Santa Barbara
> Really—I don't know what the meaning or purpose of life is.
> But it looks exactly as if something were meant by it. — C.
> G. Jung
>
> Begin forwarded message:
> > From: Robert Jonsson <rj(a)spamatica.se>
> > Date: September 23, 2005 1:23:28 PM PDT
> > To: linux-audio-dev(a)music.columbia.edu
> > Cc: Stephen Travis Pope <stp(a)create.ucsb.edu>, jackit-
> > devel(a)lists.sourceforge.net
> > Subject: Re: [linux-audio-dev] Re: [Jackit-devel] (1) Jack --
> > busted? (2) jack.udp -- busted? (3) jack-osx -- binary-only?
> >
> >
> > Hi,
> >
> > On Friday 23 Sep 2005 21:35, Eric Dantan Rzewnicki wrote:
> >> On Fri, Sep 23, 2005 at 12:10:15PM -0700, Stephen Travis Pope wrote:
> >>> (2) My actual interest is in looking into the jack-udp protocol, and
> >>> I tried getting this all to work on a Mac a few days ago and
> >>> actually
> >>> got much further, but it looks like file recv.c has problems
> >>> since it
> >>> doesn't appear to include any definition if the jackudp_t data type
> >>> that it tries to declare in the first line of code; i.e., I get,
> >>>
> >>> /Users/stp/Code/jack/jack.udp/recv.c:14: error: 'jackudp_t'
> >>> undeclared (first use in this function)
> >>>
> >>> Does jack.udp work in general?
> >>> Is there any documentation of the actual protocol used?
> >>> Has anyone thought of using TCP instead of UDP?
> >>
> >> Alban Peignier uses Rivendell with jack for radio broadcasts. As I
> >> understand it he uses jack.udp to send the audio from the
> >> broadcast box
> >> to a separate box that does encoding for web streaming. So, there
> >> is at
> >> least one working use case.
> >
> > Distributing jack interests me, but sadly I have no time to dive
> > deeper at the
> > moment.
> > Jackudp had a sibling called udpsync (not sure about the source
> > heritage)
> > which, instead of connecting two jacks through the client-interface
> > (which is
> > prone to sync problems) drives the "slave" through the backend. It
> > does
> > work, but is by no means finished.
> > Don't know if it's of interest, the latest sources are here anyway:
> > http://sourceforge.net/projects/netjack
> >
> >
> > Regards,
> > Robert
> >
> > --
> > http://spamatica.se/musicsite/
--
http://spamatica.se/musicsite/
Hi all!
I'm trying to design a library, which should provide "graphical objects" for
the console. Meaning standardised buttons, checkboxes, sliders, etc. The
purpose of this project is: to bring gui-based audio-software to the console.
What I'm wondering now is the following:
It would still be a certain amount of work, to program a textbased ui with
this library. So which way of using this library would be best?
Could any of you imagine good ways to communicate objects of your software
to a kind of server. Something like OSC? So this server can run and you start
the program on the gui and it tells the server: I have th following objects.
Could this be a way of designing it? Would this be sensible? Or would it be
better to only provide a c++ API?
Good thoughts and ideas are wellcome.
Kindest regards
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net - the Linux TextBased Studio guide
On Sep 24, 2005, at 9:02 AM, linux-audio-dev-
request(a)music.columbia.edu wrote:
> Is anyone interested in collaborating on a common sample streaming
> protocol (possibly based on a somewhat simplified version of SDIF or
> the SC3 protocol)?
I'd recommend using RTP as your base protocol, and defining your
SPIF or SC3-like payload as an RTP payload format. You'll pick up
the entire IETF multimedia protocols for free this way, including RTP
MIDI:
http://www.cs.berkeley.edu/~lazzaro/rtpmidi/index.html
I think when it comes to networking, the writing is on the wall when
in comes to packet loss being a part of the environment you need
to live in. Most new purchases of computers are for laptop computers,
most of those users want to use WiFi as their network, and the Internet
layer sees 1-2% packet loss on WiFi. Also, we live in an era where
people want to run LAN apps on the WAN and WAN apps on the LAN,
and packet loss is also an unavoidable part of the WAN Internet
experience.
Finally, modern applications want to use link-local Internet multicast.
RTP was built for letting payload formats handle packet losses in
a way that makes sense for the media type -- RTP MIDI is an extreme
example of this, but the audio and video payload formats are loss
tolerant in more subtle ways. RTP is also multi-cast compatible.
Finally, with RTP there's a standardized way to use RTSP and SIP
for your session management if you wish, or if you prefer, you can
just build RTP into whatever session manager you have committed
to (like jack).
---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---