Hey,
I just got a new box and two hammerfall 9636 cards for a project at work.
The motherboard is a KT4 Ultra that has some onboard audio chip I don't
care about but can't turn off either in the bios.
I've put in the first hammerfall card, got alsa 0.9.0 rc7 from the
freshrpms site (it's a redhat box), and started configuring things.
I've got the feeling I'm missing some things, so here are some simple
questions.
a) It looks like the Hammerfall driver doesn't have a mixer interface, is
this correct ?
Here's an ls in the relevant dir:
[root@framboos asound]# ls card0/
id pcm0c pcm0p rme9652
b) It looks like the onboard audio chip is controlled by an OSS driver, it
doesn't show up in the alsa drivers either, which is fine by me, since I'm
not going to use it. Is there any problem with OSS modules being loaded
at the same time as ALSA modules ?
c) I bought the card so I could record optical S/PDIF. The manual says I
need to tell the card that I want the ADAT1 Input source to be Optical
S/PDIF.
Right now I get, in /proc/asound/card0/rme9652:
[root@framboos card0]# cat rme9652
RME Digi9636 (Rev 1.5) (Card #1)
Buffers: capture cdc00000 playback cda00000
IRQ: 5 Registers bus: 0xde000000 VM: 0xd088a000
Control register: 44008
Latency: 1024 samples (2 periods of 4096 bytes)
Hardware pointer (frames): 0
Passthru: no
Clock mode: autosync
Pref. sync source: ADAT1
ADAT1 Input source: ADAT1 optical
IEC958 input: Coaxial
IEC958 output: Coaxial only
IEC958 quality: Consumer
IEC958 emphasis: off
IEC958 Dolby: off
IEC958 sample rate: error flag set
ADAT Sample rate: 44100Hz
ADAT1: No Lock
ADAT2: No Lock
ADAT3: No Lock
Timecode signal: no
Punch Status:
1: off 2: off 3: off 4: off 5: off 6: off 7: off 8: off
9: off 10: off 11: off 12: off 13: off 14: off 15: off 16: off
17: off 18: off
Which I read as the Input source being ADAT optical instead of S/PDIF.
How do I set it to S/PDIF ?
d) the card came with a sub-D-connector that connects to the card's 15 pin
port, which branches off two RCA jacks. I don't suppose these RCA jacks
provide an analogue output by any chance on which I can monitor for sound
?
I'm sure I'll bug you with more questions later on, but these are the most
pressing ones at this point.
Any help is greatly appreciated.
Thomas
--
The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
<-*- thomas (dot) apestaart (dot) org -*->
Oh, baby, give me one more chance
<-*- thomas (at) apestaart (dot) org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/
i like the recently suggested new hints. i'd like to add the
following, which would allow hosts to do the right thing with
both SooperLooper and SC4, which are the first (only?) LADSPA plugins
to have control output ports, but use them in very different ways. its
almost impossible as it stands to build a GUI for them both that does
them justice.
--p
/* Hint LADSPA_HINT_OUTPUT_METER indicates that the value of output
control port is likely to be most meaningful to the user if
displayed as a meter. Can be combined with LADSPA_HINT_LOGARITHMIC
if the meter should use a log scale (e.g. dB).
*/
#define LADSPA_HINT_OUTPUT_METER 0x??
/* Hint LADSPA_HINT_OUTPUT_VALUE indicates that the value of output
control port is likely to be most meaningful to the user if
displayed as some kind of numeric value display.
*/
#define LADSPA_HINT_OUTPUT_VALUE 0x??
We've posted an update about our forthcoming 24/192 portable recorder:
http://www.core-sound.com/HighResRecorderNews.html
It runs on an iPAQ and the Linux version of the software uses Familiar/GPE
and ALSA.
Thanks to all for the high level of interest!
Len Moskowitz
Core Sound
Hi everyone,
The months fly off the calendar, and the time for the
next IETF meeting arrives (in San Francisco later this month).
Pick up the latest version of the MWPP I-D's at:
http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-mwpp.txthttp://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-guide.txt
Back at the end of the last meeting, I had predicted these
documents would be "candidate Last Call" (the end of the writing
process and the beginning of the vetting process ...), but alas,
it was not meant to be. But I really think we're only a month
away or so ... the things left to do are doable and not overwhelming.
-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
Think this needs to go to LAD too...
--- Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> wrote:
> I think there was one more too, but I can't think what it was...
I remember one about sidechains or something. I don't know what a sidechain is,
though, I just recall seeing it somewhere :)
> I agree AUDIO_RATE_CONTROL should be renamed.
>
> There was a suggestion on ardour-dev that a hint to say whether control outs
> were supposed to be informative or a source of control data might help,
> but I'm not sure about it.
Not sure what 'informative' means here... what information do we get if we
ignore the control data on the output?
> Does someone want to reword these in a more meaningful way? If not I'l do
> it, then you'l be sorry ;).
I'll have a go :)
(The LADSPA_IS_* things will need to be added too)
/* Hint MOMENTARY indicates that that a control should behave like a
momentary switch, such as a reset or sync control. LADSPA_HINT_MOMENTARY
may only be used in combination with LADSPA_HINT_TOGGLED. */
#define LADSPA_HINT_MOMENTARY 0x40
/* Hint RANDOMISABLE indicates that it's meaningful to randomise the port
if the user hits a button. This is useful for the steps of control
sequencers, reverbs, and just about anything that's complex. A control
with this hint should not result in anything too suprising happening to
the user (eg. sudden +100dB gain would be unpleasant). */
#define LADSPA_HINT_RANDOMISABLE 0x80
/* Plugin Ports:
Plugins have `ports' that are inputs or outputs for audio or
data. Ports can communicate arrays of LADSPA_Data (for audio
or continuous control inputs/outputs) or single LADSPA_Data values
(for control input/outputs). This information is encapsulated in the
LADSPA_PortDescriptor type which is assembled by ORing individual
properties together.
Note that a port must be an input or an output port but not both
and that a port must be one of either control, audio or continuous. */
[...]
/* Property LADSPA_PORT_CONTINUOUS_CONTROL indicates that the port is
a control port with data supplied at audio rate. */
#define LADSPA_PORT_CONTINUOUS_CONTROL 0x10
-
Mike
>
> - Steve
>
> > On Wed, 15 Jan 2003 18:13:35 +0000
> > Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> wrote:
> >
> > > There have been a few suggestions recently, I'l try to summarise them
> > > for comment.
> > >
> > > MOMENTARY. A hint to suggest that a control should behave like a
> > > momentary switch, eg. on for as long as the user holds down the
> > > key/mouse button/whatever. Useful for reset or sync controls for
> > > example. Would be useful in the DJ flanger. Only applies to TOGGLED
> > > controls.
> > >
> > > AUDIO_RATE_CONTROL. Hints than an audio control should/could be
> > > controlled by a high time res. slider or control data, but shouldn't
> > > be connected to the next audio signal by default. I can't think of any
> > > simple examples off hand, but combined with MOMENTARY it could be used
> > > for sample accurate tempo tapping.
> > >
> > > RANDOMISABLE. Hints that its useful/meaningful to randomise the port
> > > if the user hits a button. This is useful for the steps of control
> > > sequencers, reverbs, and just about anything that's complex. Allows
> > > you to specify which controls can be randomised without anything too
> > > supprising happening to the user (eg. sudden +100dB gain would be
> > > unpleasent).
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
bob mentioned issues with the serial port. i'd like to amplify
that. if you are using a serial modem (COM1, COM2) etc, and you don't
specify "EXPERIMENTAL" source support, you won't even have a chance to
build the serial driver. once you do build it, it won't work for PPP
(in my experience).
I have been working on an audio processing/synthesis application that
should have the power of Reason and Buzz plus the ability to be used
effectivly in live proformance. Some of you may have read my earlier
emails on this subject. I call it Voltage.
The main features that I want but are not availiable in other software
are:
- Linux and Open-Source
- the ability to route and process sequence data (MIDI like data). This
would allow very powerful chordization and arpegiation.
- the ability to create sequence loops in a flexible way (like Reason
Matrix except without the limitations). I'd also like to be able to
record/modify them live without stoping the playback.
- the ability to control things in complex ways using scripting of some
sort (maybe as a machine that is scripted to create certain sequence
events)
What I am looking for is someone to help me (an inexperienced software
designer) design this program. That person don't nesseserily need to
help code the program. I've desided I need help after multiple failed
attempts. I think my current ideas are closer to a working design than
past ones, but I don't want to code it then find out doesn't work (like
I did last time round).
If you are willing to help or have any tips or books I should read, etc.
please email me.
Thanks much.
-Arthur
--
Arthur Peters <amp(a)singingwizard.org>
Hi!
On Tue, Feb 25, 2003 at 07:48:11PM +0200, Kai Vehmanen wrote:
> Date: Tue, 25 Feb 2003 12:20:22 -0500
> From: Paul Davis <paul(a)linuxaudiosystems.com>
> Reply-To: linux-audio-dev(a)music.columbia.edu
> To: linux-audio-dev(a)music.columbia.edu
> Subject: Re: [linux-audio-dev] Fwd: CSL Motivation
>
> >There are discussions on kde-multimedia about
> >the future of Linux/Unix multimedia (especially sound).
> >This is one of the most interesting messages.
>
> CSL is proposed primarily as a wrapper layer around existing APIs. as
> such, it seems to me to have no particular merits over PortAudio,
> which has the distinct advantages of (1) existing
CSL also "exists".
> (2) working on many platforms already and
You're right about that one: CSL is not as complete as PortAudio w.r.t to
portability.
> (3) using well-developed abstractions.
I do not believe that something is ever a "well-developed abstraction" by
itself. Something is always a "well-developed abstraction" from something,
designed to achieve a certain purpose. From the PortAudio homepage:
| PortAudio is intended to promote the exchange of audio synthesis software
| between developers on different platforms, and was recently selected as the
| audio component of a larger PortMusic project that includes MIDI and sound
| file support.
This clearly states the purpose: if you want to write audio synthesis software,
then you should use PortAudio. Then, I assume, the abstraction is well-
developed. However, it does not state:
"... is intended to play sound samples with sound servers easily. Or: ... is
intended to port existing applications easily. Or: ... is intended to let
the application choose its programming model freely."
No. PortAudio makes a lot of choices for the software developer, and thus
provides an easy abstraction. This will mean, however, that actually porting
software to PortAudio will probably be hard (compared to CSL), whereas
writing new software for PortAudio might be convenient, _if_ the software
falls in the scope of what the abstraction was made for.
> CSL was
> written as if PortAudio doesn't exist. I don't know if this a NIH
> attitude, or something else, but I see little reason not use consider
> PortAudio as *the* CSL, and by corollary, little reason to develop Yet
> Another Wrapper API.
Well, I gave you some. The paper gives some more. Basically, CSL is intended
for porting _most_ free software, whereas PortAudio is intended for portable
synthesis software.
I think PortAudio would benefit in _supporting_ CSL, rather than aRts for
instance, because CSL is more generic ; once new sound servers (like MAS)
come up, you need not patch PortAudio all the time, but just one place: a
CSL driver. The same is valid for other meta-frameworks like SDL.
> the only reason i was happy writing JACK was
> precisely because its not another wrapper API - it specifically
> removes 90% of the API present in ALSA, OSS and other similar HAL-type
> APIs.
I am glad you did write JACK, although back then I thought it was just another
try to redo aRts (and we had some heated discussions back then), because some
people seem to like it. If some people will like CSL, why not?
If you added CSL support to JACK right now, you would never need to bother
with any of the "sound server guys" like me again, because you could always
say: "support CSL in your sound server thing, and then JACK will support your
sound server".
On the other hand, if you added JACK support to CSL, you could also mix the
output of all of these "sound servers" into JACK, without endangering your
latency properties.
Cu... Stefan
--
-* Stefan Westerfeld, stefan(a)space.twc.de (PGP!), Hamburg/Germany
KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
Hallo,
with the LAD meeting getting closer, I'm getting a bit curious about,
what the plans are for the open "Linux Sound Night" on 15.3.? Will we
hear some of you guys perform and Paul records it?
ciao
--
Frank Barknecht _ ______footils.org__