Re: [linux-audio-dev] latency measuring software
jfm3 wrote: I can't get latencytest-0.42 to run on Redhat 7.3. I would like to make sure that the kernels I've been building are doing what I want. Does anybody have this working, or are there other audio latency measuring tools around? Grab http://www.zip.com.au/~akpm/linux/amlat.tar.gz and use `realfeel' and/or `realfeel2'. Just start them running and start stressing the computer; watch the output. It's much simpler. -
Re: [linux-audio-dev] RFC: API for audio across network -inter-host audio routing
Peter Hanappe wrote: I wondered if it would be possible to write a JACK driver (i.e. replacement for current ALSA driver) that would stream the audio over a network. The driver is a shared object, so it's technically possible. I was thinking of the timing issues. Concerning the timing issues, one of the problem raised by audio transmission is the audio cards clock skew of the different stations involved in the transmission. I've done some work on this topic. It's available as a technical report at ftp://ftp.grame.fr/pub/Documents/AudioClockSkew.pdf Hoping that it may help, -- Dominique Fober [EMAIL PROTECTED] -- GRAME - Centre National de Creation Musicale - 9 rue du Garet 69001 Lyon France tel:+33 (0)4 720 737 06 fax:+33 (0)4 720 737 01 http://www.grame.fr
RE: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing
Thanx for the info. Unfortunately it does not really get clear to me what the project does. I think the difference to my approach is that I am talking about LAN and low latency (10ms) Men -Original Message- From: [EMAIL PROTECTED] [mailto:linux-audio-dev- [EMAIL PROTECTED]] On Behalf Of Steve Harris Sent: Mittwoch, 12. Juni 2002 20:03 To: [EMAIL PROTECTED] Subject: Re: [linux-audio-dev] RFC: API for audio across network - inter- host audio routing On Wed, Jun 12, 2002 at 06:25:14 +0200, Men Muheim wrote: Has anyone ever thought of implementing a library for transfer of audio across networks? The API could be similar to JACK but would allow Have a look at MAS, they had an impressive demo at LinuxTag: http://mediaapplicationserver.net/ It works with X but doesn't require it IIRC. That API is not that similar to jack, but hey. - Steve
RE: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing
Concerning the timing issues, one of the problem raised by audio transmission is the audio cards clock skew of the different stations involved in the transmission. I've done some work on this topic. It's available as a technical report at ftp://ftp.grame.fr/pub/Documents/AudioClockSkew.pdf Hoping that it may help, I am aware of clock skew. Therefore we either need synchronization as available with IEEE1394 or a clock skew compensation as you describe it in your paper. - Men PS: Where and when was your paper published. Maybe I would like to cite it.
RE: [linux-audio-dev] RFC: API for audio across network -inter-host audio routing
Indeed I have and it is, in fact, what I plan to be spending most of this summer working on. I don't know if you've seen gison's magic, but it sounds very similar what you're doing: http://magic.gibson.com/ Looks interesting. Thanks for the info. Magic seems to be a network like replacement for ADAT/MADI, if I understand the specification correctly. According to my opinion this is still too audio sample oriented. I would like to have one network which allows IP communication as well as audio routing. IEEE1394b seems to be a good choice for that. It allows sample synchronization, provides QoS and supports UTP cabling up to 100m. The discussion here should not be about the network but about an audio API which is independent of the underlying network stack. During the last year I have implemented a library that does such a thing for a custom, synchronous network. Perhaps we can help each other? My intention was to write either an alsa driver, or a seperate magic driver, that deals with all the magic network stuff, while exporting interfaces to alsa or jack, or whatever api fancies using the magic network. I think the first thing to do is to define an audio API that reflects network capabilities and design the according audio library / server. Maybe the server could base on some of the JACK technology. Only after that the network driver comes into place. What do you think? I'm eager to see your code :) I guess just publishing my code would not help too much without any documentation or explanation. A minor problem is that the code is not my property but belongs to the Swiss Federal Institute of Technology as I am employed by them. But I am sure I could convince them that making the code open source would help more than just burying it in an archive:-) Give me some time to check that... Regards, Men
Re: [linux-audio-dev] Poll about linux music audio app usability
Chris Butt wrote: But yeah, could something like agnula or the lad site have a 'so you want to help but you can't compile alsa' or 'things for people with little skill but enthusiasm'? sounds like a very good idea to me. i'll think about it some more. ideas welcome. (preferably off-list, we can go back to public discussion as soon as there is a first draft on the LAD page.) regards, jörn
[linux-audio-dev] LinuxTag2002 photos from the LAD/ALSA booth
hello everyone ! the photos from the joint LAD/ALSA booth at LinuxTag 2002 in karlsruhe/germany are now available at http://www.linuxdj.com/audio/lad/events.php3 . those who asked for t-shirts will find a link to the image there. it's probably easier to find a print shop close to you and roll your own than to fedex shirts around the world. for some general info about LinuxTag, go to http://www.linuxtag.org/ (in german; there is a link to the english version in the top right corner. the page probably does not reflect yet that the show is over.) we will most definitely have a booth again next year. if you'd like to participate, write to me off-list ([EMAIL PROTECTED]), i'll collect your address and forward it to the organizers when the preparations start (usually around february). best regards, jörn
Re: [linux-audio-dev] Poll about linux music audio app usability
The problem seems to be either... A) That there aren't enough of these people to go around. B) That these people aren't in touch with the people who want to write code, or just have a hard time coordinating with them. or C) That these people aren't very deeply involved with the linux / free software circles... maybe because being a good designer doesn't necessarily make one a good geek. Personally speaking, I think one of the most interesting areas of audio app design is the user interface, because there is no really obvious way of doing it. I'm really interested in unusual solutions to these problems, and not necessarily only visually - I'd quite like to get a text based interface to SSM one day. One of the things I'm always slightly disappointed in Linux apps (including my own) is the lack of originality of interface and ideas, too many clones of existing solutions - when we have the freedom and lack of commercial worries to do whatever we want. Dave : www.pawfal.org :
Re: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing
On Thu, Jun 13, 2002 at 11:45:13 +0200, Men Muheim wrote: Thanx for the info. Unfortunately it does not really get clear to me what the project does. I think the difference to my approach is that I am talking about LAN and low latency (10ms) MAS works over LANs, and should be capable of 10ms latency, which isn't very low by BTW. You certainly can't play an instrument with 10ms latency. - Steve
Re: [linux-audio-dev] RFC: API for audio across network - inter-hostaudio routing
* Charlie Baker [EMAIL PROTECTED] when everything isn't roses, you don't get any headroom - Thomas Dolby New Toy * On Thu, 13 Jun 2002, Steve Harris wrote: On Thu, Jun 13, 2002 at 11:45:13 +0200, Men Muheim wrote: Thanx for the info. Unfortunately it does not really get clear to me what the project does. I think the difference to my approach is that I am talking about LAN and low latency (10ms) MAS works over LANs, and should be capable of 10ms latency, which isn't very low by BTW. You certainly can't play an instrument with 10ms latency. Nonsense! What about tubas ? I admit a guitar would feel pretty awful w/ 10 ms latency, an oboe or trumpet only fells a little slow to speak, and a Tuba , well, that would be an exceptionally responsive low brass... CharlieB - Steve
Re: [linux-audio-dev] hdsp output, and the lack of
Ok so I hit play in Ardour, here is what I got numid=13,iface=PCM,name='Output Peak',index=1 ; type=INTEGER,access=r,values=2,min=0,max=0,step=0 : values=0,0 numid=13,iface=PCM,name='Output Peak',index=1 ; type=INTEGER,access=r,values=2,min=0,max=0,step=0 : values=0,0 numid=13,iface=PCM,name='Output Peak',index=1 ; type=INTEGER,access=r,values=2,min=0,max=0,step=0 : values=3899648,0 numid=13,iface=PCM,name='Output Peak',index=1 ; type=INTEGER,access=r,values=2,min=0,max=0,step=0 : values=5140736,0 numid=13,iface=PCM,name='Output Peak',index=1 ; type=INTEGER,access=r,values=2,min=0,max=0,step=0 : values=4853248,0 numid=13,iface=PCM,name='Output Peak',index=1 ; type=INTEGER,access=r,values=2,min=0,max=0,step=0 : values=8019712,0 numid=13,iface=PCM,name='Output Peak',index=1 ; type=INTEGER,access=r,values=2,min=0,max=0,step=0 : values=8943360,0 numid=13,iface=PCM,name='Output Peak',index=1 ; type=INTEGER,access=r,values=2,min=0,max=0,step=0 : values=10902272,0 the value changes when I hit the play button in Ardour, and returns to 0 on stop. I setup amixer in a 1 second loop, so the values are at 1 sec intervals On Wed, 2002-06-12 at 08:38, Paul Davis wrote: Puzzling. Very puzzling. Can you run some input into the system and see if the Input Peak readings change? They should. Read them using: amixer -c N cget numid=13 this will read the input peak value for channel 1 over and over again. i'd like to see that this at least is working. N is the card number for your hdsp. --p -- I have a switch in my apartment that doesn't do anything. Every once in a while I turn it on and off. On and off. On and off. One day I got a call from a woman in France who said Cut it out! -- Steven Wright
Re: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing
On Thursday 13 June 2002 09:29 am, Charlieb wrote: On Thu, 13 Jun 2002, Steve Harris wrote: MAS works over LANs, and should be capable of 10ms latency, which isn't very low by BTW. You certainly can't play an instrument with 10ms latency. Nonsense! What about tubas ? I admit a guitar would feel pretty awful w/ 10 ms latency, an oboe or trumpet only fells a little slow to speak, and a Tuba , well, that would be an exceptionally responsive low brass... French Horn. Its bore is as long as a tuba's. I have played horn before, and there is a definite, barely detectable delay between initiation of the note and the perception of the note (which is both by ear and by hand in the case of the horn). The long bore is one reason the horn's attack is quite mellow. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing
You certainly can't play an instrument with 10ms latency. in 10ms sound travels somewhat more than 3 meters. that why i use nearfield monitors :) --martijn
Re: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing
On Thu, Jun 13, 2002 at 01:29:11 +, Charlieb wrote: MAS works over LANs, and should be capable of 10ms latency, which isn't very low by BTW. You certainly can't play an instrument with 10ms latency. Nonsense! What about tubas ? I admit a guitar would feel pretty awful w/ 10 ms latency, an oboe or trumpet only fells a little slow to speak, and a Tuba , well, that would be an exceptionally responsive low brass... OK, I admit I have never tried playing a tuba with 10ms latency (at all infact), but I'm not sure how you would arange it anyway! Though... an electric tuba is a intreguing thought ;) I would guess that a newwork audio system for low brass instruments is a little specialised. - Steve
Re: [linux-audio-dev] Poll about linux music audio app usability
On Thu, Jun 13, 2002 at 02:02:49 +0200, Dave Griffiths wrote: One of the things I'm always slightly disappointed in Linux apps (including my own) is the lack of originality of interface and ideas, too many clones of existing solutions - when we have the freedom and lack of commercial worries to do whatever we want. I think you do yourself a disservice. Spiral loops has a great interface design. Theres a few things I would add, but its novel AFAIK, and very appropriate. - Steve
Re: [linux-audio-dev] RFC: API for audio across network - inter-hostaudio routing
MAS works over LANs, and should be capable of 10ms latency, which isn't very low by BTW. You certainly can't play an instrument with 10ms latency. Really? You might want to check my math on this, but if the speed of sound in air at 75 degrees F is about 1135 feet/second, then it takes about 0.00088 seconds, or 0.88 ms, for the sound to travel 1 foot. So in 10 ms the sound would only travel about 11.35 feet. If you were playing an electric guitar and the amp was 11 feet away, there would be a 10 ms delay and I don't think you would have a problem. I've done it many, many times without a problem anyway :) Joe -- __ | | Joseph A. Sarlo | | [EMAIL PROTECTED] |__
Re: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing
On Thu, Jun 13, 2002 at 09:43:44 -0400, Lamar Owen wrote: [latency and instruments] there is a definite, barely detectable delay between initiation of the note and the perception of the note (which is both by ear and by hand in the case of the horn). The long bore is one reason the horn's attack is quite mellow. I would describe 10ms as more than barely detectable its very noticable. 5ms (with my inexpert guitar noodling) feels uncomfortable, but is barable. YMMV. 5ms is equivalent to a ~1.7m horn. - Steve
Re: [linux-audio-dev] Poll about linux music audio app usability
On Wednesday 12 June 2002 16:37, Billy Biggs wrote: I see only two options: Go all the way, ask all users to pay, lose personal ownership of the project and turn it into a product, or ask nothing and expect nothing. Anything in between puts everyone in a bad position: users might feel obligated to contribute even though they have no guarentee of getting anything for it, or the author might feel obligated to continue working even though the financial reward is insufficient and charity rather than market driven. There's always the classic FSF model: an agreement with a particular user that needs a feature to add that feature for a specific price. The feature then becomes part of the standard open source distro (so all the community benefits). I understand Richard Stallman made a living for many years this way. Cheers! |-| |Frederick F. Gleason, Jr.|WAVA Radio - 105 FM |Voice: 1-(703)-807-2266 | | Director of Engineering |1901 N. Moore Street| FAX: 1-(703)-807-2245 | | |Arlington, VA 22209 | Web: HTTP://www.wava.com| |-| | All progress is based upon a universal innate desire of every organism | | to live beyond its income. | | -- Samuel Butler| |Notebooks | |-|
Re: [linux-audio-dev] RFC: API for audio across network - inter-hostaudio routing
On Wed, 12 Jun 2002, Steve Harris wrote: Have a look at MAS, they had an impressive demo at LinuxTag: http://mediaapplicationserver.net/ It works with X but doesn't require it IIRC. That API is not that similar to jack, but hey. Thanks for mentioning us, Steve! We're focused on network transparency and time sensitive data routing. And, we've been working with X.org to give the X Window System some standard audio support (it's about time, don't you think?!) As for the API... it's closer to hellish than stable right now. There is no pull-style playback interface component to it yet, like jack's, but we're planning on providing one alongside a traditional UNIX kind of push interface. -Mike
Re: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing
You certainly can't play an instrument with 10ms latency. Really? You might want to check my math on this, but if the speed of sound in air at 75 degrees F is about 1135 feet/second, then it takes about 0.00088 seconds, or 0.88 ms, for the sound to travel 1 foot. So in 10 ms the sound would only travel about 11.35 feet. If you were playing an electric guitar and the amp was 11 feet away, there would be a 10 ms delay and I don't think you would have a problem. I've done it many, many times without a problem anyway :) Joe There's a psychoacoustic phenomenon known as the Haas effect which states that a direct sound and it reflections (echos) are percieved as a single sound by the brain, where the time difference between the two is less than about 30ms. So if the brain can't distinguish between sounds at this level I think you'd get away with a 10ms delay in your instrument without the rest of the band calling you names :-) Barry -- [EMAIL PROTECTED]
Re: [linux-audio-dev] RFC: API for audio across network - inter-hostaudio routing
Lamar Owen wrote: On Thursday 13 June 2002 09:29 am, Charlieb wrote: On Thu, 13 Jun 2002, Steve Harris wrote: MAS works over LANs, and should be capable of 10ms latency, which isn't very low by BTW. You certainly can't play an instrument with 10ms latency. Nonsense! What about tubas ? I admit a guitar would feel pretty awful w/ 10 ms latency, an oboe or trumpet only fells a little slow to speak, and a Tuba , well, that would be an exceptionally responsive low brass... French Horn. Its bore is as long as a tuba's. I have played horn before, and there is a definite, barely detectable delay between initiation of the note and the perception of the note (which is both by ear and by hand in the case of the horn). The long bore is one reason the horn's attack is quite mellow. To say nothing of pipe organs, where the latency can be nearly half a second (!) in a large church. -dgm
Re: [linux-audio-dev] LinuxTag2002 photos from the LAD/ALSA booth
On Thursday, June 13, 2002, at 01:11 PM, Joern Nettingsmeier wrote: hello everyone ! the photos from the joint LAD/ALSA booth at LinuxTag 2002 in karlsruhe/germany are now available at http://www.linuxdj.com/audio/lad/events.php3 . those who asked for t-shirts will find a link to the image there. it's probably easier to find a print shop close to you and roll your own than to fedex shirts around the world. for some general info about LinuxTag, go to http://www.linuxtag.org/ (in german; there is a link to the english version in the top right corner. the page probably does not reflect yet that the show is over.) we will most definitely have a booth again next year. if you'd like to participate, write to me off-list ([EMAIL PROTECTED]), i'll collect your address and forward it to the organizers when the preparations start (usually around february). best regards, jörn
Re: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing
You certainly can't play an instrument with 10ms latency. See: http://ccrma-www.stanford.edu/groups/soundwire/delay_p.html http://www-ccrma.stanford.edu/groups/soundwire/delay.html http://www-ccrma.stanford.edu/groups/soundwire/WAN_aug17.html These experiments show the limits of musical latency compensation -- the full story is complicated but in general compensating for 10ms is quite doable ... Also, to address another part of this thread, I'd really recommend using RTP as an underlying technology -- don't underestimate the amount of thought and work that has been put into these standards over the past decade, start by reading: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-new-11.ps and then browse the I-D's and RFC's at: http://www.ietf.org/html.charters/avt-charter.html --jl - John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -
Re: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing
On Thursday 13 June 2002 11:59 am, dgm4 wrote: Lamar Owen wrote: French Horn. Its bore is as long as a tuba's. I have played horn before, and there is a definite, barely detectable delay between initiation of the note and the perception of the note (which is both by ear and by hand in the case of the horn). The long bore is one reason the horn's attack is quite mellow. To say nothing of pipe organs, where the latency can be nearly half a second (!) in a large church. Yeah, but organists are trained to compensate for that. That's one reason there are so many manuals. But it does make the music interesting to play. I know a concert organist who is rather accomplished; I didn't even think about his techniques when I mentioned horn. When one stop is half a second removed from another, odd and interesting effects can be produced by one who know the instrument and the acoustics of the venue well enough. But I think most musicians don't want to have to deal with the pipe organ techniques. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing
On Thursday 13 June 2002 13:15, xk wrote: I'm not a professional musician, but a 25 ms latency makes me more than happy. It really depends upon the specific application. For some problem-spaces (radio automation, for example), latency is just not a very important issue. For others (e.g. live performance sound reinforcement), it can be critical. Cheers! |-| |Frederick F. Gleason, Jr.|WAVA Radio - 105 FM |Voice: 1-(703)-807-2266 | | Director of Engineering |1901 N. Moore Street| FAX: 1-(703)-807-2245 | | |Arlington, VA 22209 | Web: HTTP://www.wava.com| |-| | It is one thing to praise discipline, and another to submit to it.| | -- Cervantes | |-|
RE: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing
In my experience, audible separation of acoustic events normally happens around 20ms (ignoring phase effects). Most instruments (including guitar) are entirely playable with this sort of delay. The pipe organ example is a good one - there is a huge variety of delay on pipe organs, probably beyond the half second (I don't have the figures, but there's often a significant delay between keypress and note as well as the acoustic delay). I'm fine with small delays, but fast passages becomes continuously less comfortable as the delay increases. The same is true for other instruments such as guitar. BTW, as I keep moaning, I think network audio is an important next step in LAD development and ideally could be combined with the kind of step required to get JACK firmly off the ground. I'm still plugging LADMEA ideas (www.ladspa.org/ladmea/). --Richard
Re: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing
How about the 1.0-1.5 ms latencies that everbody tries to obtain (or already has) in both Linux/Win world? That always made me wonder if this isn't just hype like the 192 kHz issue. I'm not a professional musician, but a 25 ms latency makes me more than happy. I would say that for playing a software synthesizer realtime a latency of 10ms or less is ok. I'm not sure what latency most hardware synthesizers have, but this will probably not be much better, sometimes even more than 10ms. Only the transmission of a noteon/off MIDI command will use 1ms (3 * 320usec, no running status). --martijn
Re: [linux-audio-dev] Poll about linux music audio app usability
On Thu, 13 Jun 2002, Fred Gleason wrote: On Wednesday 12 June 2002 16:37, Billy Biggs wrote: I see only two options: Go all the way, ask all users to pay, lose personal ownership of the project and turn it into a product, or ask nothing and expect nothing. Anything in between puts everyone in a bad position: users might feel obligated to contribute even though they have no guarentee of getting anything for it, or the author might feel obligated to continue working even though the financial reward is insufficient and charity rather than market driven. There's always the classic FSF model: an agreement with a particular user that needs a feature to add that feature for a specific price. The feature then becomes part of the standard open source distro (so all the community benefits). I understand Richard Stallman made a living for many years this way. And what happened to sites like sourceXchange? Regardless, I don't think there is much consumer interest in this model because consumers can't afford my salary, nor are they willing to pay for something until they see the finished, working product: there is too much poorly written software out there to trust money to random developers, even those with good track records. That said, I don't want all software to be written for corporations either. Software companies don't want soft-synths or drum machines, the bulk of that market is consumers and prosumers, and what few companies that do (studios etc) can't afford my salary either, especially if I'm competing with commercial software that's only a few hundred dollars per fully featured app. -- Billy Biggs [EMAIL PROTECTED] http://www.div8.net/billy [EMAIL PROTECTED]
Re: [linux-audio-dev] RFC: API for audio across network -inter-host audio routing
On Thu, 2002-06-13 at 01:39, Dan Hollis wrote: We hold a patent on MaGIC Curious. -- Bob Ham: [EMAIL PROTECTED] http://pkl.net/~node/ My music: http://mp3.com/obelisk_uk GNU Hurd: http://hurd.gnu.org/
[OT] RE: [linux-audio-dev] RFC: API for audio across network -inter-host audio routing
The pipe organ example is a good one - there is a huge variety of delay on pipe organs, probably beyond the half second (I don't have the figures, but there's often a significant delay between keypress and note as well as the acoustic delay). I'm fine with small delays, but fast passages becomes continuously less comfortable as the delay increases. The same is true for getting off-topic now. But have you ever measured the latency between the organ and the audience in the church singing? It makes me sick of church songs but nevertheless *some* people like it that way... Well, it obviously depends on the instrument what latency is OK. tobias.
Re: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing
On Thu, Jun 13, 2002 at 01:29:11PM +, Charlieb wrote: * Charlie Baker [EMAIL PROTECTED] when everything isn't roses, you don't get any headroom - Thomas Dolby New Toy * On Thu, 13 Jun 2002, Steve Harris wrote: On Thu, Jun 13, 2002 at 11:45:13 +0200, Men Muheim wrote: Thanx for the info. Unfortunately it does not really get clear to me what the project does. I think the difference to my approach is that I am talking about LAN and low latency (10ms) MAS works over LANs, and should be capable of 10ms latency, which isn't very low by BTW. You certainly can't play an instrument with 10ms latency. Nonsense! What about tubas ? I admit a guitar would feel pretty awful w/ 10 ms latency, And yet electric guitarists do it all the time. Ever stood 10 feet away from your amp? It's no big deal, you get used to it. -- Paul Winkler home: http://www.slinkp.com Muppet Labs, where the future is made - today!
[linux-audio-dev] De-interleaving
Something's odd here...
I'm trying to de-interleave the stereo output from sfront
into discrete channel buffers suitable for jack. Everything's
fine when number of channels = 1; but when it's 2, it seems
that I get the left channel in both outputs. I've confirmed
that the left and right outputs are different when running
with oss audio output instead of jack.
I have a buffer called tempbuf, which contains nframes channel-interleaved
sample frames. Call it tempbuf. e.g.:
long nframes;
long nsamples = nframes * ASYS_OCHAN;
/* ASYS_OCHAN is the number of channels */
float* tempbuf = (float*) calloc(nsamples, sizeof(float));
next, I set up an array of buffers into which I want to put
the deinterleaved output:
float* obuf[ASYS_OCHAN];
for(i=0; i ASYS_OCHAN; i++) {
obuf[i] = (float*) calloc(nframes, sizeof(float));
/* actually I use jack_port_get_buffer() instead of calloc... */
/* and actually there are various typedefs in use, not float */
}
That's all fine, as far as I can tell. Now here's the de-interleaving
code:
for(i=0; i nsamples; i++) {
obuf[i % ASYS_OCHAN][i / ASYS_OCHAN] = tempbuf[i];
}
The effect this *should* have (when ASYS_OCHAN = 2):
obuf[0][0] = tempbuf[0]
obuf[1][0] = tempbuf[1]
obuf[0][1] = tempbuf[2]
obuf[1][1] = tempbuf[3]
obuf[0][2] = tempbuf[4]
obuf[1][2] = tempbuf[5]
...
... but I'm hearing the left output on both channels.
Have I made some silly mistake in the de-interleaving?
Any other ideas on what I could've done wrong?
Complete actual code attached if anyone wants to see more
context...
--
Paul Winkler
home: http://www.slinkp.com
Muppet Labs, where the future is made - today!
/* TO TO:
- do asys_isetup and asys_iosetup.
- FIgure out why 2-channel output is working but sounds
totally fucked up.
- buffer size change:
jack_get_buffer_size() can be called ONLY before client activation
to find out current max buffer size.
While running, if jack changes buffer size, it calls function registered
with jack_set_buffer_size_callback.
On the sfront side:
asys_orun's 2nd argument is a pointer to long whose value represents
the max number of sample periods available.
Hmm, I'm not sure I need to register a function with jack;
looks like sfront can handle any buffer size at any time
(as long as it is a multiple of the number of channels).
*/
/*
#Sfront, a SAOL to C translator
#This file: jackd audio driver for sfront
#copyright (c) 2002 Paul M. Winkler, Brooklyn, NY
# www.slinkp.com
#
#This program is free software; you can redistribute it and/or modify
#it under the terms of the GNU General Public License (Version 2) as
#published by the Free Software Foundation.
#
#This program is distributed in the hope that it will be useful,
#but WITHOUT ANY WARRANTY; without even the implied warranty of
#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
#GNU General Public License for more details.
#
#You should have received a copy of the GNU General Public License
#along with this program; if not, write to the Free Software
#Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
#
#Maintainer: Paul Winkler www.slinkp.com
*/
/* includes needed for JACK */
#include stdio.h
#include errno.h
#include unistd.h
#include jack/jack.h
/* include glib.h */
/* defines needed by sfront */
#define ASYSN_JACK_DEBUG 1 /* debugging printouts */
#define ASYSN_JACK_SLEEPMS 5 /* exit interval */
/* declarations needed for jack */
jack_port_t *asysn_jack_input_port[ASYS_ICHAN] ;
jack_port_t *asysn_jack_output_port[ASYS_OCHAN];
jack_client_t *asysn_jack_client;
/* declarations needed for sfront */
volatile int asysn_jack_proc_status; /* used to signal status */
/* my own stuff */
char asysn_jack_client_name[256] = SAOL Test Client;
int asysn_jack_srate_was_called = 0;
int asysn_jack_oports_connected = 0;
int asysn_jack_iports_connected = 0;
void asysn_jack_print_usage(void);
void asysn_jack_print_usage(void) {
fprintf(stderr, Usage: ... write useful blahblah here\n);
}
/* callback functions used by jack in various scenarios */
/** OUTPUT ONLY **/
#if defined(ASYS_HASOUTPUT) !defined(ASYS_HASINPUT)
int asysn_jack_process (jack_nframes_t nframes, void * arg )
/* cast arg to pointer to whatever I need. */
{
/* OUTPUT ONLY */
/* vars. copied from portaudio driver
but this is my jack process() function, which only gets
a nframes a pointer-to-void argument.
*/
long nsamples = (long) nframes * ASYS_OCHAN;
long oremaining = nsamples ;
long optr = 0;
long osize;
jack_default_audio_sample_t* obuf[ASYS_OCHAN];
ASYS_OTYPE* tempbuf;
int i, j;
if (asysn_jack_srate_was_called 1) {
/* force jack to remove this client as per PBD message on jackit-devel
on 4/24/02 (thread: stereo?)
*/
printf(uh-oh... called srate again, and we can't handle it\n);
return
Re: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing
On Thu, Jun 13, 2002 at 12:41:52 -0400, Paul Winkler wrote: Nonsense! What about tubas ? I admit a guitar would feel pretty awful w/ 10 ms latency, And yet electric guitarists do it all the time. Ever stood 10 feet away from your amp? It's no big deal, you get used to it. Thats true, but doesn't match my experience of trying to play with 512 sample buffers... although that probably doesn't equate to 512 samples of latency, its probably more. I'l have to try it with a hardware delay line. - Steve
Re: [linux-audio-dev] De-interleaving
On Thu, Jun 13, 2002 at 04:42:55PM -0400, Paul Winkler wrote:
Something's odd here...
I'm trying to de-interleave the stereo output from sfront
into discrete channel buffers suitable for jack. Everything's
fine when number of channels = 1; but when it's 2, it seems
that I get the left channel in both outputs. I've confirmed
that the left and right outputs are different when running
with oss audio output instead of jack.
do you have an .asoundrc, and are you telling jack to use a hardware
card? (do you get the message about using the plug layer or whatever)?
the invocation should be something along the lines of
jackd -R -d alsa -d card0
or whatever the name its given in the asoundrc
rob
Robert Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: [EMAIL PROTECTED]
Re: [linux-audio-dev] RFC: API for audio across network -inter-host audio routing
This prompted me to look at my course notes, and here's a quote: A patent may be granted for an invention only if following conditions are satisfied: The invention is new; It involves an inventive step; It is capable of industrial application; The grant for a patent for it is not excluded by subsections (2) and (3) below... The exclusions referred to include: A scheme, rule or method for performing any mental act, playing a game or doing business, or a program for a computer; However, the Act only applies to a patent or application for a patent relating to a thing _as such_. I don't know what else they can patent; I certainly wouldn't imagine a protocol would be patentable. I hope there's not something else. Any other people in the UK know anything about this? Bob -- Bob Ham: [EMAIL PROTECTED] http://pkl.net/~node/ My music: http://mp3.com/obelisk_uk GNU Hurd: http://hurd.gnu.org/
