On Thu, 6 Dec 2001 23:09:14 -0700
Richard Gooch <[EMAIL PROTECTED]> wrote:
> Rene Rebe writes:
> > At least since 2.4.17-pre4 and -pre5 devfs is not handling
> > permissions in the right way with ALSA:
>
> Please define what is the "right way".
Sorry I toght the commands wabout would be enought
> I read up on timers, and fixed that problem too. This is an updated
> patch, and I'm happy to say that the tumbler now works perfectly :)
And one last addition (I hope).
<< 4 isn't enough volume at the top. Reading the TAS3001C docs I came
across a huge table, which I implemented, and which
Rene Rebe writes:
> At least since 2.4.17-pre4 and -pre5 devfs is not handling
> permissions in the right way with ALSA:
Please define what is the "right way".
> rene@jackson:/dev > l dsp sound/dsp
> ls: sound/dsp: Permission denied
> lr-xr-xr-x 1 root root9 Dec 7 00:14 dsp -
Hi
Still nit-picking, but the following code is just ugly, and I cannot see any reason
for writing it this way. From card_emu10k1.c (and a few other files in card/, as a
quick look shows), the snd_emu10k1_probe(...), starting at line 97:
for ( ; dev < SNDRV_CARDS; dev++) {
if (!snd_ena
On Thu, Dec 06, 2001 at 06:35:06PM +0100, Takashi Iwai wrote:
> As mentioned in the last mail, it's just because of implementation of
> VARIABLE length events. If it's VARUSR event, no need for that.
> So far, both length-types are checked according the event type, and
> SYSEX is assigned only to
On Thu, Dec 06, 2001 at 06:31:11PM +0100, Takashi Iwai wrote:
> Hi Michanel,
>
> thanks for great document!
> i'll put it into alsa-lib code for doxygen.
Thank you! This sounds great. I'll try to make a habit of writing
this sort of thing, since you liked this one so much :)
I'm primarily rel
> however, atomic.h is a *kernel header*, and linus has made it very
> clear that no user space program should ever include these headers.
>
> the solution is quite simple (and the one he advocates): copy the
> contents of the header file to a new location and use that. most of my
> code includes
>#ifdef __KERNEL__
>
>#define ATOMIC_INIT(i) { (i) }
>
>#define atomic_read(v) ((v)->counter)
>#define atomic_set(v,i) (((v)->counter) = (i))
>
>
>etc.
>
>Not using atomic reads where they are necessary would seem like a bad
>idea. Are the ones in pcm_meter (and maybe they are u
I read up on timers, and fixed that problem too. This is an updated
patch, and I'm happy to say that the tumbler now works perfectly :)
jack.
Index: keywest.c
===
RCS file: /cvsroot/alsa/alsa-driver/cards/ppc/keywest.c,v
retrievi
The current CVS version of ALSA is broken for ibook2 tumbler based
cards. After digging in quite a bit, I finally found and fixed several
bugs, although there is still one more pending.
The attached patched fixes the initialization and with it, one can play
sounds normally. (before the driver w
Hi.
At least since 2.4.17-pre4 and -pre5 devfs is not handling permissions in the
right way with ALSA:
rene@jackson:/dev > l dsp sound/dsp
ls: sound/dsp: Permission denied
lr-xr-xr-x 1 root root9 Dec 7 00:14 dsp -> sound/dsp
rene@jackson:/dev > cd sound/
bash: cd: sound/: Per
I just tried to compile alsa-lib from CVS, and it gave me errors. It
seems that atomic_read and friends are only available for kernel
processes, not for userland. At least that's the way it is on PPC:
#ifdef __KERNEL__
#define ATOMIC_INIT(i) { (i) }
#define atomic_read(v) ((v)->coun
any words on this?
_J
In the new year, Jeremy Hall wrote:
> Hi,
>
> I can't find a difference in the way audioengine and jack open / configure
> the alsa device, but audioengine works, jack does not. Jack DOES work on
> a single card, just not when both cards are linked. Abramo, do you have
>
On 6 Dec 2001, Scott Barnes wrote:
> On Thu, 2001-12-06 at 12:48, Jaroslav Kysela wrote:
> > On Thu, 6 Dec 2001, Takashi Iwai wrote:
> >
> > > At Wed, 5 Dec 2001 12:54:23 -0500,
> > > Scott Barnes wrote:
> > > >
> > > > I'm not a subscriber of this list, so CC me.
> > > >
> > > > I managed to mak
On Thu, 2001-12-06 at 12:22, Takashi Iwai wrote:
> At Wed, 5 Dec 2001 12:54:23 -0500,
> Scott Barnes wrote:
> >
> > I'm not a subscriber of this list, so CC me.
> >
> > I managed to make the cs4236 alsa driver work with the CS4237B in the
> > Dell Inspiron 3000 (making it the FIRST driver in li
On Thu, 2001-12-06 at 12:48, Jaroslav Kysela wrote:
> On Thu, 6 Dec 2001, Takashi Iwai wrote:
>
> > At Wed, 5 Dec 2001 12:54:23 -0500,
> > Scott Barnes wrote:
> > >
> > > I'm not a subscriber of this list, so CC me.
> > >
> > > I managed to make the cs4236 alsa driver work with the CS4237B in the
On Thu, 6 Dec 2001, Takashi Iwai wrote:
> At Wed, 5 Dec 2001 12:54:23 -0500,
> Scott Barnes wrote:
> >
> > I'm not a subscriber of this list, so CC me.
> >
> > I managed to make the cs4236 alsa driver work with the CS4237B in the
> > Dell Inspiron 3000 (making it the FIRST driver in linux to full
Hi,
At Mon, 3 Dec 2001 15:59:23 +0200 (EET),
Timo Tossavainen wrote:
>
>
> Hi,
>
> I've been developing a simple realtime bassline softsynth (osc, adsr, lp
> filter) for ALSA (controlled using midi ports in alsa sequencer). The idea
> is to ultimately build a system that allows one to connect
Hi,
i replied in the reverse order..
At Wed, 5 Dec 2001 01:16:35 -0500,
Michael Ashton wrote:
>
>
> I've been poking through the sequencer code a bit, and noticed two
> things which puzzle me. Both are to do with the way variable-length
> events are transmitted:
>
> 1. Why does snd_seq_event
Hi Michanel,
thanks for great document!
i'll put it into alsa-lib code for doxygen.
At Wed, 5 Dec 2001 01:23:15 -0500,
Michael Ashton wrote:
>
>
> Wrote a bit of "documentation" based on my reading of the sequencer
> code. It's an attempt to answer the question "how does one send and
> receiv
At Wed, 5 Dec 2001 12:54:23 -0500,
Scott Barnes wrote:
>
> I'm not a subscriber of this list, so CC me.
>
> I managed to make the cs4236 alsa driver work with the CS4237B in the
> Dell Inspiron 3000 (making it the FIRST driver in linux to fully
> support it without any problems). The required
On 6 Dec 2001, Josh Green wrote:
> On Wed, 2001-12-05 at 19:12, Paul Davis wrote:
> > this is somewhat like the kind of behaviour one sees on the
> > trident. why are they not synchronized? well, in part because they
> > designed the h/w to have *independent* playback and capture streams,
> > whi
On Wed, 2001-12-05 at 19:12, Paul Davis wrote:
> this is somewhat like the kind of behaviour one sees on the
> trident. why are they not synchronized? well, in part because they
> designed the h/w to have *independent* playback and capture streams,
> which reflects typical consumer use. if you for
On Thu, 6 Dec 2001, Kyle Centers wrote:
> I hate to be nit picky, but I have been trying to figure something out, and am at a
>complete loss.
>
> In alsa-drivers, the file card-emu10k1.c, line 79 or there about reads:
>
> static struct pci_device_id snd_emu10k1_ids[] __devinitdata = {
>
> After
On Wed, 5 Dec 2001, Paul Davis wrote:
> >Your patch doesn't take care about frequencies other than 48000Hz, because
> >stimer is absolute 48000Hz timer, so the spurious threshold should be
> >adjusted for other sample rates as well. I've put your code with my
> >modifications to the CVS tree.
>
>
25 matches
Mail list logo
