hi list,
I have problems installing the emi26 on my box running fc3 & ccrma. I
rebuilt a kernel with the necessary module and reinstalled alsa
afterwards. it looks fine actually, even when I start alsa it loads
the module for the emi26. unfortunately it does not work yet. what did
I miss out??
my settings in modprobe.conf look like this::
alias snd-card-0 emi26
alias sound-slot-0 snd-card-0
options snd-card-0 index=0
alias snd-card-1 snd-usb-audio
options snd-card-1 index=1
alias snd-card-2 snd-intel8x0
alias sound-slot-2 snd-intel8x0
options snd-card-2 index=2
alias snd-card-3 snd-virmidi
options snd-card-3 index=3
I also did 'depmod -a' afterwards and restarted alsa. the messages
seemed to have emi26 loaded, also when I do this::
[karlos@posthuman ~]$ lsmod
Module Size Used by
snd_virmidi 8384 0
snd_seq_virmidi 12288 1 snd_virmidi
snd_seq_midi_event 12032 1 snd_seq_virmidi
snd_seq 59536 2 snd_seq_virmidi,snd_seq_midi_event
snd_intel8x0 36800 1
snd_ac97_codec 76792 1 snd_intel8x0
snd_usb_audio 70336 0
snd_pcm_oss 57632 0
snd_mixer_oss 23552 2 snd_pcm_oss
snd_pcm 99204 4
snd_intel8x0,snd_ac97_codec,snd_usb_audio,snd_pcm_oss
snd_timer 30340 2 snd_seq,snd_pcm
snd_usb_lib 17408 1 snd_usb_audio
snd_rawmidi 29472 2 snd_seq_virmidi,snd_usb_lib
snd_seq_device 13196 2 snd_seq,snd_rawmidi
snd 62052 13
snd_virmidi,snd_seq_virmidi,snd_seq,snd_intel8x0,snd_ac97_codec,snd_usb_audio,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_usb_lib,snd_rawmidi,snd_seq_device
soundcore 14304 2 snd
emi26 168704 0
but it is not claimed by any device. I have it connected and the blue
LED it lit, so I wonder what the heck I do wrong. should I see more
lights, green ones? I have not used the emi26 with something else so I
don't know.
any ideas?
thanks,
Karsten
>From: Jens M Andreasen <jens.andreasen(a)chello.se>
>
> $ ogg123 http://oggtrial.nm.cbc.ca:80/cbcr2-toronto.ogg
>
>It is only 32Kbit but, considering the low bandwith, sounds amazingly
>good. There are some annoying artifacts though:
>
> Piano, Viola da Gamba etc "flutters" reminiscent of a cassette player.
[ ... ]
>Oh, and remember to visit their feedback section to give them a thumbs
Thumbs down, I hope.
mp3 flutters/bubbles as well at low rates.
Juhana
--
http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
for developers of open source graphics software
>From: Alfons Adriaensen <fons.adriaensen(a)alcatel.be>
>>
>> Why not? Flac + open DVD-audio format for N channels.
>
>Do you know any DVD-A player that has a FLAC decoder built in ?
>The DVD-A spec does not allow anything but MLP, or no compression,
>so no manufacturer will ever make such a thing.
If EU wants that other media players should run in Windows,
perhaps EU would look bad the DVD-Audio spec as well.
Whoever designed the spec, it was stupid not to look around for
non-patented/non-proprietary lossless format as an alternative.
We just have to work out the suitable modification/extension to
the spec. How vdix/dvix format ended up to be a standard in DVD
video players? How mp3-discs in CD player? And how the various
copycontrol systems on CDs?
Juhana
--
http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
for developers of open source graphics software
Hi,
this question is mostly for Thomas Charbonnel, I suppose, as he was
working on this a while ago...
Is the Alsa driver for the RME HDSP MADI already up and running?
sincerely,
Marije
Hi,
Hopefully this is within the scope of this list but following a lot of
recent googling, there doesn't appear to be any interest in
"open-sourcing" anything related to DVD-Audio.
As you may know, commercially authored DVD-Audio disks have three very
unfriendly features - encryption, watermarking and Meridian Lossless
Packing (MLP). I am assuming that these are some of the reasons
developers have not become interested in DVD-Audio.
However, none of those features are compulsory, and if you remove those
obstacles (which I am not interested in overcoming - simply avoiding),
you are left with a standard which allows 18 combinations of samplerate
and sample wordsize for 2-channel stereo audio (including 16-bit/44.1KHz
RedBook, and going all the way up to 24-bit/192KHz), plus a range of
6-channel uncompressed surround sound formats.
My aim is to produce a set of GPL'd tools to both author, "un-author",
and play such unencrypted, uncompressed disks, and am curious to know if
any other developers have an interest in this area or not.
To this end, I've started the "dvd-audio" project at sourceforge -
http://sourceforge.net/projects/dvd-audio/ I have not yet populated the
site with HTML content or any of the software I'm in the process of
developing, but there is a "dvd-audio-devel" mailing list which anyone
is welcome to subscribe to.
I should reiterate that I'm not interested in investigating features
such as encryption or MLP - I simply wish to be able to author my own
unencrypted and uncompressed DVD-Audio disks using my own music, which I
can then play back either on my hardware DVD-Audio player or on my PC,
all using free software
Regards,
Dave.
My impression is that more and more applications are moving to
OSC for inter-process communication.
Question 1: Are most audio/midi applications converging on OSC?
Are there any moving away from it? Or are there other strong
contenters in this area?
AFAIK all linux audio/midi applications use an arbitrary UDP port
number, and rely on manual configuration of this for the server and
all clients.
With OSC popularity increasing this will pose a growing problem
for end users who have to configure the ports, and for developers
of client programs that want to interact with multiple servers.
The answer to this issue is service discovery, which was recently
discussed on the OSC_dev list [1]. That thread leads to a product
called howl [2], which is an open implementation of mDNS/redezvous/
zeroconf (take your pick). It provides 3 daemons (of which 2 should
be run) and some libraries.
Using this implementation all applications would (ideally) register
or discover services using the howl libraries. Apart from this, the
programs would communicate via OSC.
To me this seems like a lot of overhead for a relatively small gain.
OTOH it seems like a very flexible and future-proof solution.
An alternate way I've been considering is an OSC-based service
discovery daemon. It would accept OSC messages to register and discover
services. The advantage of this is that it only uses 1 small daemon,
but more importantly that applications do not need to use any additional
libraries besides the OSC one (<insert liblo plug here> :). So far I
can see 6 input messages for such a daemon, with 4 response messages.
The disadvantage is that the daemon would still need an arbitrary port
number, and all applications would need to know it (at least for a while).
For intra-host discover the daemon could still interact with howl or
something like it if that is needed. But if this approach is successfull
we could request one dedicated port from IANA.
Question 2: Are there other better alternatives?
Question 3: Which alternative is better or do you prefer? (mDNS/OSC-daemon)
The only thing I haven't mentioned yet is LASH. Well, in my opinion it
is the prime example of an application that needs to interact with all
other linux audio/midi appications. As such, I think it could gain most
from a service discovery scheme. And there has been talk about using
OSC for it [3].
Comments/suggestions/questions? Blast away! Phasers on stun please!
And Steve: appologies for stepping on your turf.
Best regards,
--
Martin
[1] http://www.create.ucsb.edu/pipermail/osc_dev/2004-December/000841.html
[2] http://www.porchdogsoft.com/products/howl/
[3] http://music.columbia.edu/pipermail/linux-audio-dev/2004-August/009288.html
[4] http://www.cnmat.berkeley.edu/OpenSoundControl/
---------------------------------------------------------------------------
30 years from now GNU/Linux will be as redundant a term as UNIX/MERT is
today. - Martin Habets
---------------------------------------------------------------------------
Hello,
I'm looking for the 'official' (ANSI/IEC/ITU/???) specs for the set of
1/3 octave bandpass filters used for sound analysis. ISTR there are
different grades, depending on precision and filter order. If someone
would have them (or a pointer) please drop me line.
TIA,
--
Fons
Hi!
CBC Toronto is evaluating the Ogg Vorbis format for Internet streaming.
You can find it here:
$ ogg123 http://oggtrial.nm.cbc.ca:80/cbcr2-toronto.ogg
It is only 32Kbit but, considering the low bandwith, sounds amazingly
good. There are some annoying artifacts though:
Certain announcers gets very metallic voices
Piano, Viola da Gamba etc "flutters" reminiscent of a cassette player.
Any idea why it flutters? Is it my player, their encoding setup or
perhaps a limitation in the Vorbis codec itself?
Oh, and remember to visit their feedback section to give them a thumbs
up :)
--
(
)
c[] // Jens M Andreasen
Hi everyone,
Just a quick note on discovery from the RTP MIDI
experience:
http://www.cs.berkeley.edu/~lazzaro/rtpmidi/index.html
The assumption we're making is that existing IETF
session management tools -- the Real Time Streaming
Protocol (RTSP) for applications that feel like content
distribution, and the Session Initiation Protocol (SIP) for
applications that feel like telephony -- will be the way
RTP MIDI (together with audio and video and text, etc)
sessions will get set up, and that the mechanisms these
tools use for discovery will be used for RTP MIDI.
On SIPPING (the place where new SIP frameworks
are born and raised):
http://www.ietf.org/html.charters/sipping-charter.html
there has been a lot of activity recently about
"p2p SIP architectures", which in a LAN context is the
sort of discovery people are talking about here (link-local
multicast, the backbone of mDNS, is the LAN tool at the
bottom). But there's also an interest in making these
p2p SIP architectures work outside a LAN context, which
is where the "p2p" comes from -- they look for inspiration
from the file-sharing world for discovery (Distributed Hash
Tables, etc) ...
Also, note that basic SIP already has some link-local
multicast support -- a new phone coming on line can
sent a REGISTER to a well-known local multicast address
and port, where any SIP proxies online will be listening.
This doesn't solve the bigger question of how you make
an architecture where even phone is also a SIP proxy,
and act to serve each other ... which is what the SIPPING
work is about.
---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---
