Re: [Alsa-devel] Quick question

[Paul Davis]

>I guess this means that I will have to start reading JACK documentation 
>in earnest. I trust that there is such a thing.. ;)

there is reference documentation generated by docbook using jack.h.
there is also a directory full of working example clients that you can
copy and modify to do whatever you want.


---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] Quick question

[David Stuart]

[EMAIL PROTECTED] wrote:

Jack is so great, many developers on this list have named their children
after it. Do the right thing.
LOL! That's a good one! David, meet Jack. David, Jack. David, Jack. ... 
"Is your name not Jack?" .. "no" ..."that's going to cause a little 
confusion, mind if we call you Jack, just to keep it clear?"

Well OK, I guess all of the lobbying here (in the ALSA-dev mailing list 
of all places) has convinced me that JACK is indeed the way to go. At 
the very least I could suggest that our customers install the CCRMA on 
top of their RedHat platform..

My only complaint with the CCRMA stuff is that it forces them to install 
apt-get, which is not really sound related, and not packaged with RedHat 
by default. But apart from that (which is indeed a very minor beef) it 
seems like a great idea to have a low-latency pre-packaged solution. 
Certainly this is a lot easier than telling them how to patch their 
kernel, etc.

I guess this means that I will have to start reading JACK documentation 
in earnest. I trust that there is such a thing.. ;)





---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] Quick question

[jfm3]

> and no, you don't need to modify anything about your stock RH system to
> use JACK. the modifications are only needed if you want low
> latency, and such modifications would be needed to get this with just
> ALSA anyway. a jack client will run just as well as a native ALSA
> (better in some senses) when the jack server is run with equivalent
> parameters for the audio hardware.

Not only that, but there's Planet CCRMA, which allows you to make
automated RPM package updates to your stock RH (like up2date or
red-carpet, but cooler) that give you the low latency kernel, precompiled
ALSA drivers, and enough Jack apps to keep you busy for quite some time.

Jack is so great, many developers on this list have named their children
after it. Do the right thing.

(jfm3)




---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] Quick question

[Jan Depner]

David,

I don't know that much about the internals of JACK but I do know this -
all serious Linux sound apps either use or are preparing to use JACK. 
I've gotten to the point where I look for that in an application.  If
it's not JACK enabled I just move on to something else.

Jan


On Tue, 2003-06-03 at 19:38, Paul Davis wrote:
> >Ah, I think you misunderstand me a little bit.. it's not that I am
> >trying to do anything different than usual, it's that I'm having trouble
> >with the basics. Specifically, the HOW-TOs that I have found all seem to
> >have a different way of writing and reading to/from the hardware buffer.
> 
> thats because there are multiple ways to do it.
> 
> >I have not, as of yet, been able to find a clear description of the core
> >concepts around writing and reading to the device. Also some recommend
> >one way, and then another HOWTO says not to do it that way.. it's all
> >rather confusing.
> 
> if you want something that's not confusing, then JACK is your
> friend. it was specifically designed to cut away all the complexity
> and force you to write a well-designed application (and yes, its me
> who gets to define what well-designed means :)
> 
> and no, you don't need to modify anything about your stock RH system
> to use JACK. the modifications are only needed if you want low
> latency, and such modifications would be needed to get this with just
> ALSA anyway. a jack client will run just as well as a native ALSA
> (better in some senses) when the jack server is run with equivalent
> parameters for the audio hardware.
> 
> >For instance, I'm really not sure what size my buffer needs to be, if
> >there is a difference between the "hardware buffer" and the buffer in my
> >program, How "periods" work into all this, what's the difference between
> >hw and plughw, etc. Also each of the examples seems to configure the
> >hardware differently, which I find also odd..
> 
> there are many ways of doing this too.
> 
> >So to sum it up, the problem is not only that I'm new to ALSA, but that
> >I'm new to sound programming in general. Is there somewhere I can go to
> >learn the basics (at least enough to do capture and playback, beyond
> >that I'm not as interested)?
> 
> if you're trying to learn sound programming, the last thing you want
> to be messing with is a hardware abstraction layer that can handle any
> audio h/w you can imagine. do yourself a favor and use jack
> instead. you can focus on audio programming rather than how to setup
> an audio interface. better yet, your application will talk to other
> jack-enabled applications if and when you want to.
> 
> --p
> 
> 
> 
> 
> ---
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> ___
> Alsa-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/alsa-devel




---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] Quick question

[Paul Davis]

>Ah, I think you misunderstand me a little bit.. it's not that I am
>trying to do anything different than usual, it's that I'm having trouble
>with the basics. Specifically, the HOW-TOs that I have found all seem to
>have a different way of writing and reading to/from the hardware buffer.

thats because there are multiple ways to do it.

>I have not, as of yet, been able to find a clear description of the core
>concepts around writing and reading to the device. Also some recommend
>one way, and then another HOWTO says not to do it that way.. it's all
>rather confusing.

if you want something that's not confusing, then JACK is your
friend. it was specifically designed to cut away all the complexity
and force you to write a well-designed application (and yes, its me
who gets to define what well-designed means :)

and no, you don't need to modify anything about your stock RH system
to use JACK. the modifications are only needed if you want low
latency, and such modifications would be needed to get this with just
ALSA anyway. a jack client will run just as well as a native ALSA
(better in some senses) when the jack server is run with equivalent
parameters for the audio hardware.

>For instance, I'm really not sure what size my buffer needs to be, if
>there is a difference between the "hardware buffer" and the buffer in my
>program, How "periods" work into all this, what's the difference between
>hw and plughw, etc. Also each of the examples seems to configure the
>hardware differently, which I find also odd..

there are many ways of doing this too.

>So to sum it up, the problem is not only that I'm new to ALSA, but that
>I'm new to sound programming in general. Is there somewhere I can go to
>learn the basics (at least enough to do capture and playback, beyond
>that I'm not as interested)?

if you're trying to learn sound programming, the last thing you want
to be messing with is a hardware abstraction layer that can handle any
audio h/w you can imagine. do yourself a favor and use jack
instead. you can focus on audio programming rather than how to setup
an audio interface. better yet, your application will talk to other
jack-enabled applications if and when you want to.

--p




---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] Quick question

[David Stuart]

On Tue, 2003-06-03 at 09:18, Paul Davis wrote:

> its also very unclear what you want help with. there is nothing
> particularly different about capture and playback on 2 devices
> compared to doing it on just 1.

Ah, I think you misunderstand me a little bit.. it's not that I am
trying to do anything different than usual, it's that I'm having trouble
with the basics. Specifically, the HOW-TOs that I have found all seem to
have a different way of writing and reading to/from the hardware buffer.
I have not, as of yet, been able to find a clear description of the core
concepts around writing and reading to the device. Also some recommend
one way, and then another HOWTO says not to do it that way.. it's all
rather confusing.

For instance, I'm really not sure what size my buffer needs to be, if
there is a difference between the "hardware buffer" and the buffer in my
program, How "periods" work into all this, what's the difference between
hw and plughw, etc. Also each of the examples seems to configure the
hardware differently, which I find also odd..

So to sum it up, the problem is not only that I'm new to ALSA, but that
I'm new to sound programming in general. Is there somewhere I can go to
learn the basics (at least enough to do capture and playback, beyond
that I'm not as interested)?


-- 
David Stuart, SIPQuest
phone: 254-8886 x234 web: http://www.sipquest.com/



---
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

RE: [Alsa-devel] Quick question

[Mark Knecht]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of David Stuart
> Sent: Tuesday, June 03, 2003 6:53 AM
> To: David E. Storey
> Cc: alsa
> Subject: Re: [Alsa-devel] Quick question
>
>
> Ah! I do exist! :)
>

>
> 1) It's relatively easy to install (from rpms anyway)
> 2) One does not have to tinker too much with a default RedHat (our
> "tested" distro) installation to use ALSA.
> 3) It has good full-duplex support, as opposed to the default OSS setup.
> 4) JACK is the future, but not yet the present (seems to me)


Hi,
Since you're on Redhat, you can install Alsa and Jack very easily using the
PlanetCCRMA flow in less than an hour. Check it out if you're interested.

Cheers,
Mark




---
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] Quick question

[David Stuart]

Ah! I do exist! :)

Perhaps a better description of what I'm trying to do is in order. I
don't know if anyone here is familiar with JMF (java media framework),
but I would like to create an ALSA capture plugin on Linux very similar
to the "direct sound" one that's available on the Windows platform.

When I said that I would like to capture and then playback on TWO
devices, in reality they will probably be always the SAME device (in
full duplex mode). Hopefully that makes the problem easier. This small
test program was my way of getting started.

I realize that JACK is probably the wave of the future in this respect,
but I was thinking of using ALSA because:

1) It's relatively easy to install (from rpms anyway)
2) One does not have to tinker too much with a default RedHat (our
"tested" distro) installation to use ALSA.
3) It has good full-duplex support, as opposed to the default OSS setup.
4) JACK is the future, but not yet the present (seems to me)

Although I admittedly haven't tried JACK yet, I was suspecting that
using ALSA directly would require our customers to do less customization
of their default RedHat installation than installing ALSA + JACK. I need
to keep the procedure simple because we will have to support them.


On Tue, 2003-06-03 at 09:25, David E. Storey wrote:
> Having said that, your question involved using TWO devices, which I
> believe jack doesn't really support unless you're "bonding" them a la
> your .asoundrc file. (and even then, you'd really want to syncronize
> their clocks which most, if not all, consumer products don't support.)
> Assuming you don't care about clock synchronization, you could follow
> the examples at . Just open
> up one device for capture and the other for playback. When you receive
> data from one, pass it to the other.

Hmm .. I did find this HOWTO once before (and a few others), and tried
to follow them, but I must be doing something wrong because I can't get
more than a few pops out of my playback device. I was hoping that
someone could either tell me what I was doing wrong in my program, or
provide a small working example that I could use to learn from..


-- 
David Stuart, SIPQuest
phone: 254-8886 x234 web: http://www.sipquest.com/



---
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] Quick question

[David E. Storey]

Well, I would have answered your question, but I personally don't have
the answers you seek. For starters, I wouldn't use alsa for doing such
things. I'd use Jack.  It's so much more
flexible, powerful and easier to code for than straight alsa.

Having said that, your question involved using TWO devices, which I
believe jack doesn't really support unless you're "bonding" them a la
your .asoundrc file. (and even then, you'd really want to syncronize
their clocks which most, if not all, consumer products don't support.)
Assuming you don't care about clock synchronization, you could follow
the examples at . Just open
up one device for capture and the other for playback. When you receive
data from one, pass it to the other.

(and reading Paul's recent post on jack, apparently you can do what you
want to do with jack.)

d!

On Tue, 2003-06-03 at 09:05, David Stuart wrote:
> Apparently the ALSA community is too busy to answer my little questions,
> this is the sadly the 3rd or 4th time I has posted to this list with no
> answer. :(
> 
> I don't think my question is too difficult. All I'm asking for is a
> little help! Either a small snippet or a pointer to some other
> information.. Maybe my question is too newbie-ish, but you can't develop
> new experts without said experts being newbies at one time.
> 
> 
> On Mon, 2003-06-02 at 16:01, David Stuart wrote:
> > Does anyone have a short example of capturing from one device and doing
> > a playback (of the captured data) on another?


signature.asc
Description: This is a digitally signed message part

Re: [Alsa-devel] Quick question

[Paul Davis]

>I don't think my question is too difficult. All I'm asking for is a
>little help! Either a small snippet or a pointer to some other
>information.. Maybe my question is too newbie-ish, but you can't develop
>new experts without said experts being newbies at one time.

its not a little question. its something that is not done very often
at all. in fact, i don't know of a single piece of code that does it,
although theoretically the most recent version of JACK could do so,
since it allows different PCM device names for playback and
capture. its hardly a "simple example" however.

its also very unclear what you want help with. there is nothing
particularly different about capture and playback on 2 devices
compared to doing it on just 1.







---
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] Quick question

[Patrick Shirkey]

David Stuart wrote:
Apparently the ALSA community is too busy to answer my little questions,
this is the sadly the 3rd or 4th time I has posted to this list with no
answer. :(
I don't think my question is too difficult. All I'm asking for is a
little help! Either a small snippet or a pointer to some other
information.. Maybe my question is too newbie-ish, but you can't develop
new experts without said experts being newbies at one time.
On Mon, 2003-06-02 at 16:01, David Stuart wrote:

Does anyone have a short example of capturing from one device and doing
a playback (of the captured data) on another?


Check out ecasound. It can do this quite easily apparently.



--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide

Being on stage with the band in front of crowds shouting, "Get off! No! 
We want normal music!", I think that was more like acting than anything 
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman


---
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] Quick question

[David Stuart]

Apparently the ALSA community is too busy to answer my little questions,
this is the sadly the 3rd or 4th time I has posted to this list with no
answer. :(

I don't think my question is too difficult. All I'm asking for is a
little help! Either a small snippet or a pointer to some other
information.. Maybe my question is too newbie-ish, but you can't develop
new experts without said experts being newbies at one time.


On Mon, 2003-06-02 at 16:01, David Stuart wrote:
> Does anyone have a short example of capturing from one device and doing
> a playback (of the captured data) on another?

-- 
David Stuart, SIPQuest
phone: 254-8886 x234 web: http://www.sipquest.com/



---
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel