Re: [Alsa-devel] Starting playback/capture exactly the same time (was: Repeatable exact I/O-delay)

>Thanks. I'll try this. Not only the hardware can be broken, but also >the driver I suppose. It seems like not all have support for >snd_pcm_link(), for example my driver for RME96 (I have to do some >maintenance work on that soon). no code is needed to implement support for this. its handled

Re: [Alsa-devel] Repeatable exact I/O-delay

>By the way, I tried to search for the same code in rme9652.c, and found >something similar, but it does not seem to activate both capture and >playback with a single write to the control register. I'm not sure how >the hardware works (nor the driver) though so I may be wrong. there are no di

Re: [Alsa-devel] Repeatable exact I/O-delay

>I've looked through some driver code, and if I understand it correctly, >it seems like some drivers, for example the ens1370, check in the >trigger function the substream is linked with other substreams on the yes, sorry, i forgot about this aspect of things. i was thinking of snd_pcm_link()

Re: [Alsa-devel] libasound and libpthread

>I am working with Alsa 0.9.0beta12 version and I am also using posix >threads (libpthread) in my project. In the release version of the >program I link both libraries (libpthread, libasound) dynamically and >everything works well. In the debug version however, I have to do static >linking of

Re: [Alsa-devel] ALSA docs

>> i would personally work from a complete set of snd-* modules, and use >> modinfo(1) + perl to get the information > >Isn't that what happens in the INSTALL file anyway? it doesn't look like it. there are several cards missing there, and it looks hand-written rather then fetched from the source

Re: [Alsa-devel] ALSA docs

>Do you mean that I should be parsing each driver file seperately? not really, just do a single pass over each one of them at some point in time. store the results, and use them. this should get you started (its not perfect, but it doesn't do a bad job. #!/usr/local/bin/perl while(<>) {

Re: [Alsa-devel] guitar + sblive + ardour + ladspa effects

>This is what I want to do: guitar into the line input on the live drive, >that going into ardour, through a few ladspa effects, and out to the >speakers. I can't seem to do this. The only way I seem to be able to >get the input into ardour is to have it going through the speakers as >well so th

Re: [Alsa-devel] Multiple PCM files

>Sorry I am new to ALSA so forgive me if this is obvious. don't be sorry about that. instead, be sorry for this: whether you know it or not, the email program you are using is sending out copies of your mail in both plain text and HTML formats. increasingly on the net, there are filters being put

Re: [Alsa-devel] Multiple PCM files

>Ok set the option ( you guessed it Outlook Express ) to text only. Sorry >don't have a go at me as it is the default setting I believe. > >Option 1 or 2 would be what I am looking at. What I have is a program with >multiple threads needing to play PCM streams to the same device. there are some h

Re: [Alsa-devel] Multiple PCM files

>So does JACKs allow two separate applications to stream PCM audio at the >same time to the same device and if so will it then overlay them? If it will >why would two threads each registering with JACKs not work. it might, but it would be very inefficient. every JACK connection requires a new thr

Re: AW: [Alsa-devel] general audio card Q

>>i'm not exactly shure, what is double-buffers... the turtle beach >>pinnacle/fiji has shared memory, that can be accessed >>simultanously from the pc & the sound card. > >Some cards/chipsets (RME PST, ESS solo1) allow one to transfer >data for playback (record is similar) using a memory-mapped

Re: AW: [Alsa-devel] general audio card Q

>Paul wrote: > >> cards that do not use DMA should generally be considered inferior >> because of the extra CPU cycles they force on the host system. > >not generally. i.e. the pinnacle/fiji way is to map a piece of memory into >the pc's memory space. >thus an application using alsa-mmap can write

Re: AW: [Alsa-devel] general audio card Q

>Thanks for your reply and the education. My main reason behind asking >this question is that I am using the RME PST card presently to do >CPU controlled transfer of data to the memory mapped buffers in those >cards. I am interested in using the CPU to do the transfer since >I have heard that DMA

Re: [Alsa-devel] Re: Multiple PCM files

>Exactly. I would prefer the second as if I needed to add a third, 4th its >takes no effort and I don't reinvent the wheel as they say. > >Does alsa support 2 or is this just JACK's. No, ALSA does not support it *in general*. Some interfaces will work this way, some will not. In theory, the ALSA

Re: [Alsa-devel] echo hardware

>On Fri, 2 Aug 2002, Pete Black wrote: >> They indicated 1-2 weeks until driver release, but it is now going on 3 >> weeks i think, so I don't hold out too much hope for a prompt release. > >They have released it here: >http://www.echoaudio.com/Download/Developer/EchoGenericDriverA0.zip wow. no

Re: [Alsa-devel] Event Gina/Layla/Darla drivers

>I am going to set up a sourceforge project, and admin an email list and >website for the development of this driver. As 'project admin', i will >be happy to make contact with Echo corporation and request a hardware >loan on behalf of the project. i personally think doing this on sf.net is si

Re: [Alsa-devel] SNDRV_PCM_IOCTL_HW_FREE failed

>Hi, this may well be nothing to do with alsa but I thought you may know >what is happening. >If I make a system call from one thread whilst recording or playing in >another thread using the alsa lib, then when I try to snd_pcm_close I get: > > >ALSA lib pcm_hw.c:145:(snd_pcm_hw_hw_free) SNDRV_P

Re: [Alsa-devel] current buglets

>known bugs i know of (and am working on) are: hdsp - cold+warm boot required to get output working - 96kHz and 88.2kHz not accessible via PCM interface rme9652 - 96kHz and 88.2kHz not accessible via PCM interface wavefront - cs4232 PCM output does not work at all (produces white no

Re: [Alsa-devel] .asoundrc file

>> What is the purpose of the ctl.rme9652 declaration? My plugin devices >> seem to work without it. >> > >It is a configuration for the onboard mixer. Very little is known about >why we use it. Some programs (JACK) won't work without it. not really. the control device for a card is the way th

Re: [Alsa-devel] PCM ioctls

>There are 3 standard PCM ioctls, and a driver could potentially support others >via its own ioctl function registered in the snd_pcm_ops_t structure. Could >anyone give me a hint regarding how an application could then call such >standard and other ioctls? i'm not going to do that, but i will po

Re: [Alsa-devel] ALSA driver architecture documentation?

>Recently I started to collect some info on how to make a ALSA driver for >the Digigram VXpocket V2. Digigram decided to provide information >this PCMCIA card, on condition that a moderator is the single point of >contact with Digigram. glad they came to their senses. the existence of the RME Ham

Re: [Alsa-devel] usb-audio: variable periodsize / nframes per callback can shorten latency times

>>hmm, it's not so easy, since this will break also the assumption of >>constant period "frames" by applications. if we introduce the >>time-based period size, it won't work as compatible as older one, >>e.g. jack wouldn't run properly if the period size changes >>dynamically. this isn't true, o

Re: [Alsa-devel] PCMCIA and snd-hdsp

>after recompiling a kernel on my laptop, my RME HDSP configuration is >broken. Does anybody have a working setup with the RME PCMCIA card and >would be willing to share some information about the process of >initialization off list? i don't have the working setup (with pcmcia), but i would obvio

Re: [Alsa-devel] PCMCIA and snd-hdsp

>Now the snd-hammerfall-mem install o.k. but snd-hdsp segfaults (and I >have to reboot in order to get rid of the module). well, pcmci-cs may be at fault, but this is still a bug in the driver. it shouldn't segfault. i guess i've assumed that certain things are always true and that this is broken

Re: [Alsa-devel] PCMCIA and snd-hdsp

>For some reason, the hotplug script can't successfully load the snd-hdsp >driver but a simple >"modprobe snd-hdsp" does work. This is true at boot time (coldplug) and >upon insertion (hotplug). Can anyone offer any insight into this? i know nothing about the hotplug script of pcmcia-cs, but i

Re: [Alsa-devel] HDSP CardBus + Toshiba Satellite : found magic patch !

Patrick - I wanted to add this information to the h-dsp page, but when i try to get there from the card matrix, it seemed more work to use that form since i'm already on this list. Can you please add this note to the "Known Issues" for the H-DSP: - the PCMCIA interface requires a kernel that

Re: [Alsa-devel] snd-hdsp and PCMCIA

>asking about autoconfiguring the snd-hdsp upon card insertion I got >the following response from David Hinds, the maintainer of pcmcia-cs: > >> You probably want to be using the kernel PCMCIA subsystem, together >> with a more current version of the pcmcia-cs package. And a >> current linux-hotp

Re: [Alsa-devel] Alsa module configuration

>these are needed to load alsa modules _dynamically_. >if you're using an init script for loading the alsa, then basically >you don't need them. which script? is there one? alsasound doesn't load the OSS modules, for example. --- This sf.net

Re: [Alsa-devel] Alsa module configuration

>About OSS configuration, it was explained separately in another part >after the sentence above. but we don't provide any such script ... without it and without the modules.conf entries, any OSS program will fail, right? --- This sf.net email

[Alsa-devel] Re: [noreply@sourceforge.net: [pcmcia-cs - Multifunction Cards] RE: configuring unsupported sound-card]

>This is a message from Dave Hinds concerning autoconfiguring the >PCMCIA. I looked for pci_register_driver and grep only found it in >the binaries of snd-hdsp. Has the driver been written with the >"modern" kernel API, Dave is referring to? yes, all of ALSA does this. we use pci_module_init() a

Re: [Alsa-devel] ALSA-0.9.0rc2 and RME HammerFall

>Is there any know problems with 0.9.0rc2/Linux >2.4.19/RME HammerFall. I had a working application >using 0.9.0beta6/Linux/2.2.19/RME HammerFall, since I >am changing to a Intel P4 arch, I can't get the beta6 >to work. It fails on an ioctl with something about a >PVERSION... I would like to us

Re: [Alsa-devel] ALSA-0.9.0rc2 and RME HammerFall

> ALSA lib pcm_hw.c:579: (snd_pcm_hw_open) >SNDRV_PCM_IOCTL_PVERSION failed: Inappropriate ioctl >for device > failed to open audio device default >(Inappropriate ioctl for device) > >snd_pcm_hw_open is looks like this: > snd_pcm_hw_open(pcmp, name, card, device, >subdevice,

Re: [Alsa-devel] HDSP advanced routing (matrix mixer)

>I'm considering writing an application to control the HDSP matrix mixer, >but so far I could only figure out how to route physical inputs to the >line out (First integer value (0-25) : input, second integer value >(26-27) : line out L-R, third integer value (0-65536) : gain). Paul, >could you ple

Re: [Alsa-devel] do apps need to care for xfer_align ???

>On Fri, 6 Sep 2002, Guilhem Tardy wrote: > >> Hi all, >> >> While trying to understand snd_pcm_lib_write1(), I found that >> runtime->xfer_align is set to period_size in pcm_native.c, but wonder if it >is >> just a default? >> >> Paul Dav

Re: [Alsa-devel] under-runs and prepare()

>I understand that prepare() is used to restart playout or capture from a known >state in the driver, and wonder if it is OK to have it block until buffers >being currently played out have completed? are you asking if a low level driver should do this? if so, then the answer is no. the semantics

Re: [Alsa-devel] Why do I get broken pipe on write to a pcm in state PREPARED?

>Is it possible to adjust a stop threshold or something to get my >desired behaviour? i think you should have set the start mode to START_DATA and the start threshold appropriately. then the device would have started as soon as the buffer was full. --p ---

Re: [Alsa-devel] Why do I get broken pipe on write to a pcm in statePREPARED?

>IMHO the current behaviour is the proper behaviour as implemented by other >file descriptors, and as mandated by POSIX. > > >says regarding pipes, FIFOs and sockets: >| The write() function shall fail if: the discussion here is

Re: [Alsa-devel] Why do I get broken pipe on write to a pcm in statePREPARED?

>Please understand that it's very hard to satisfy everybody and I'm not >sure it's a worthy goal. Who do we know that would be unsatisfied by the proposed change in the behaviour of poll(2) on an ALSA device? --p --- Sponsored by: AMD - Your

Re: [Alsa-devel] Re: alsalib symbol problem

>> you probably are calling alsa from a shared object -- try >> >> dlopen ("libasound.so", RTLD_LAZY | RTLD_GLOBAL); >> >> in your module's init function. > >The need for RTLD_GLOBAL is somewhat ugly, usually one wants to load >plugins with RTLD_LOCAL. the suggestion is not that *your* plu

Re: [Alsa-devel] Configuration Spaces

>My knowledge of signals is that the period is the time it takes a signal to >complete 1 cycle. So what is the snd_pcm_hw_params_set_period used for? >Is the "period" a property of the signal, or an arbitrary property set by >the programmer for performance, fidelity, etc. no, a period in ALSA i

[Alsa-devel] Re: alsalib symbol problem

>Paul Davis <[EMAIL PROTECTED]> writes: > >>>> you probably are calling alsa from a shared object -- try >>>> >>>> dlopen ("libasound.so", RTLD_LAZY | RTLD_GLOBAL); >>>> >>>> in your module's ini

[Alsa-devel] Re: alsalib symbol problem

>Paul Davis <[EMAIL PROTECTED]> writes: > >> the problem is that libasound itself calls dlopen(), and the initial >> (non-RTLD_GLOBAL) linkage hasn't put libasound's symbol into the >> global namespace. hence, libasound's own dlopen'ed code can&#

Re: [Alsa-devel] new "in-compatible" alsa-lib PCM API

>1) build library with --with-compat-rc3 and place it to some > other directory >3) build library without --with-compat-rc3, place it to > /usr/lib as usuall >4) build alsa-utils and newer applications >5) build older applications with compatible library compiled > with --with-compat-rc3 > >

Re: [Alsa-devel] new "in-compatible" alsa-lib PCM API

>this is the /usr/share/aclocal/alsa.m4 job to provide right linking >flags depending of the library ah. typical autoconf confusion here. autoconf looks in only ONE directory by default for *.m4 files. if it was installed from a package, it probably looks in /usr/share/aclocal. if it was install

Re: [Alsa-devel] new "in-compatible" alsa-lib PCM API

>> anyway, i agree with paul that pkg-config should be used instead, >> which offers a lot more flexibility. > >That's as maybe but it's "non-standard" still isn't it? Another dependency >in a complicated world. I think it's too soon. its part of all distributions at this point. its about as st

[Alsa-devel] Re: RME9636 ADAT1 Recording

>Otherwise, if I will be using the alsa-lib plugin for >striding the channels, would I be better off using the if you ask for non-interleaved data, there is no striding going on. the hardware is not interleaved. >Intel Performance Primitives (IPP) libraries to do the >channel striding? I do wan

Re: [Alsa-devel] alsa-driver-0.9.8, jack, cmipci

>At Mon, 03 Nov 2003 14:41:51 -0500, >Jonathan Kraut wrote: >> >> >> Hello again. Further research: >> >> I tried an earlier version of jack (0.71.0) with alsa-driver-0.9.8, accessin >g hw:0,2 via my .asoundrc. I get the same result as before, but in addition th >is particular version of jackd

Re: [Alsa-devel] sequencer buffer

>again I've got a question regarding the ALSA midi sequencer. I tried to >generate Midi time code. you cannot send 100% valid MIDI time code on a Linux system without the high resolution timers patch or some other interrupt source that provides a suitable timing resolution. MIDI time code is no

Re: [Alsa-devel] Occasional metallic sound when recording (cs46xx)

>> anyway, it'd be helpful for debugging if someone can reproduce this >> certainly under a fixed condition... > >Well, about 3 times out of 7 I get the problem, so it's not hard to >reproduce at all. What I'd have to know is where to place the debugging >printk()'s or something like that :( just

Re: [Alsa-devel] Interrupt-driven (or callback/handler?), Full-duplex (simultaneous capture/playback) without using JACK

>I am trying to write an application that uses ALSA interrupt-driven >(which I guess is obtained by adding PCM handler(s) in ALSA?), >full-duplex (simultaneous capture/playback) using the ALSA PCM API >directly (i.e. not using JACK). > >My question: do I only need to register one callback/handler f

Re: [Alsa-devel] Interrupt-driven (or callback/handler?), Full-duplex (simultaneous capture/playback) without using JACK

>Many thanks for the info.! just keep in mind what jaroslav noted about signal handling context. please don't build a serious application around this mechanism. sooner or later, you may want to make a system call from the handler that violates the POSIX guarantees about what can be done. at that p

Re: [Alsa-devel] problems with 0.9.8 drivers and rme9652

>Hi, >it seems to me that with alsa 0.9.8 drivers it's not possible to load >snd-rme9652. With 0.9.7c there is no problem. The snd-hdsp driver works >in both versions (i tried both cards with both alsa versions). > >error message: >modprobe snd-rme9652 >/lib/modules/2.4.22/kernel/sound/pci/rme9652/

Re: [Alsa-devel] problems with 0.9.8 drivers and rme9652

1) just a quick note to point out that whether you know it or not, the email program you are using is sending out copies of your mail in both plain text and HTML formats. increasingly on the net, there are filters being put in place that silently dump HTML-formatted email. some mailing lists will n

Re: [Alsa-devel] smart and automatic use of dmix and dsnoop - feature suggestion.

>So, these are two numbers - and basicly all is fine as long as you dont wan= >t=20 >to excede them, but if you do, you need to use dmix or dsnoop. Why not use= >=20 >dmix and dsnoop automaticly when necessary ? Wouldnt it be possible to have= because it would be catastrophic, or, well, at least v

Re: [Alsa-devel] smart and automatic use of dmix and dsnoop - feature suggestion.

>what you say seems to be valid to me, but not if you implement smart dmix the >way I said =). The way I suggested *every* application would connect to smart >dmix, and none directly to alsa lib (except those that use devices like hw: - >and those should never be mixed). Since every stream is conne

Re: [Alsa-devel] smart and automatic use of dmix and dsnoop - feature suggestion.

>> well, my concern is that with the high-end cards, people tend to stick >> with the quality of sounds. that means, any reason to reduce the >> quality wouldn't be acceptable for some people. since dmix will do it >> silently (if needed), it might be unacceptable. > >what ? are you suggesting th

Re: [Alsa-devel] smart and automatic use of dmix and dsnoop - feature suggestion.

>On Mon, 17 Nov 2003, Paul Davis wrote: > >> >what you say seems to be valid to me, but not if you implement smart dmix t >he >> >way I said =). The way I suggested *every* application would connect to sma >rt >> >dmix, and none directly to alsa lib

Re: [Alsa-devel] smart and automatic use of dmix and dsnoop - feature suggestion.

>> the RME hardware has 16-26+ channels, but only one stream. > >Ok, > >here we come to my ignorance on sound drivers/hardware/terminology. If I ta= >lk=20 >about a stream I mean one application --> soundcard link. What would a=20 >channel be ? And what a stream if not what I defined a line up?=20

Re: [Alsa-devel] smart and automatic use of dmix and dsnoop - feature suggestion.

>> 5) I think that this sound mixing problem might be better served by >> sound servers like jack. > >Hmmm, > >actualy I did have a very close look at jack, but the problem that I saw=20 >(correct me if Im wrong here), is the fact that jack only works well if the= >=20 >applications are specificaly

Re: [Alsa-devel] Bug in rme9652 or snd_pcm_hw_params_set_rate_near()? (slave clock stuff)

> >If my hammerfall (rme9652) sound card is locked slave to 48 kHz, and I put >44.1 kHz into snd_pcm_hw_params_set_rate_near for playback it accepts it, >should it really be that way? I expected that it would set the rate to 48kHz, >since the card does not change the sample rate to 44.1 kHz (loo

[Alsa-devel] error return codes from alsa-lib

at what point, if any, did alsa-lib start returning positive E values (e.g. EBUSY) rather than -EBUSY? --p --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you creat

Re: [Alsa-devel] error return codes from alsa-lib

>On Tue, 25 Nov 2003, Paul Davis wrote: > >> at what point, if any, did alsa-lib start returning positive E >> values (e.g. EBUSY) rather than -EBUSY? > >I'm not aware. Which functions? none. its OK, i was checking errno rather than the returned value. my mistake. so

Re: [Alsa-devel] Fwd: [was Re: [linux-audio-user] Multiple (three) RME Hammerfalls... any experience]

>> I can't help you much, however, unless JACK has >> recently been worked on I think there's a 32 track >> limitation. It's known to be technically trivial. still in place at this time. there is a simple 1-2 line solution; i'm not sure if its the right one, since it simply substitutes a 64 channe

Re: [Alsa-devel] soundcard matrix (more)(

>has anyone contact with yamaha, btw? i've spoken in person with guys inside the mLAN development group (at NAMM, last februrary), and they put me in touch with a professor in south africa who has been acting as a consultant for them on a number of aspects of mLAN. i talked with him a few times to

Re: [Alsa-devel] Can't set 88.2/96kHz samplerate with Hammerfall

>On Thu, 4 Dec 2003 06:41:56 -0800, Mark Knecht <[EMAIL PROTECTED]>=20 >wrote: > >>> >>> Whenever I try to activate double speed (88.2/96kHz) mode with my RME >>> Hammerfall Lite (DIGI 9636), snd_pcm_hw_params fails with a 'Device or >>> resource busy' message. This is with the number of channels s

Re: [Alsa-devel] Can't set 88.2/96kHz samplerate with Hammerfall

>> be overjoyed that was if and when it finally does. Don't expect anythin= >g >> soon, unless you're willing to be that developer. >Actually, I'm not completely opposed to the idea. But I am totally=20 >clueless when it comes to writing device drivers, and would have no idea=20 >where to start. Do

Re: [Alsa-devel] Can't set 88.2/96kHz samplerate with Hammerfall

> >> Actually, I'm not completely opposed to the idea. But I am totally >> clueless when it comes to writing device drivers, and would have no >> idea where to start. > >Start here: http://www.alsa-project.org/documentation.php3#Driver > >You don't have to start writing the driver from scratch. You

Re: [Alsa-devel] Query devices in a non-blocking fashion

>>> I'd like to be able to query the capabilities (number of channels,=20 >>> buffer >>> size etc.) of ALSA devices in the system, even if they should be in us= >e=20 >>> by >>> some other process. The only current way to probe device capabilities = >is >>> to open a pcm, and use snd_pcm_hw_params,

Re: [Alsa-devel] Query devices in a non-blocking fashion

>We all think in the same way, but there's no simple solution for this >problem. I prefer to have such configuration information in an user-space >database accessed via an alsa-lib API. It's nothing for the kernel space. i'm not sure i agree with that. a user-space config DB could be used to desc

Re: [Alsa-devel] Query devices in a non-blocking fashion

>I don't agree. The control API (usually) is for things that don't affect >the way data is transferred between the card the the computer. it is *now*. i was just imagining a different conception of what it could be used for. > Sample

Re: [Alsa-devel] Hello guys!

>I hope ALSA supports hardware features in certain sound cards (like hardware >mixing, sound buffer memory, and so on) like DirectSound does in Windows... all that and a lot more. --- This SF.net email is sponsored by: SF.net Giveback Program.

Re: [Alsa-devel] Which API for MIDI?

>Tim Goetze wrote: >> * what kind(s) of sync-to-external will you need? >> * do you want to receive/send MIDI sysex data? >> >> last time i checked, the latter was impossible to do via the sequencer >> API (please correct if things have changed). > >Sending/receiving sysex has always been possible

[Alsa-devel] Re: [Jackit-devel] One drop-out per xrun?

>I wanted to check my knowledge of something: does an xrun necessarily >correspond to a "drop-out" in the audio stream? In other words, could >you have a drop-out WITHOUT an xrun, or an xrun WITHOUT a drop-out? Is >there a strict one-to-one correspondence between the two? a dropout occurs when t

Re: [Alsa-devel] Query devices in a non-blocking fashion

>My opinion is that a simple function could be included in alsactl which >scans for available devices, makes a list of their abilities. Everyone >uses "post-insert alsactl restore" in the modules.conf file so it would >be essentially a non issue from a user perspective. i think it needs to be s

Re: [Alsa-devel] OpenAL - ALSA interface proposal. I request for comments...

>Since there is almost nothing else to do to support the Aureal Vortex >3D processor on Linux, just as i announced some time ago i started >designing a OpenAL interface for ALSA. The design is meant to be >applicable to other hardware too. < >I made a preliminary description, from what i have done

Re: [Alsa-devel] snd-rme9652 fails

i'm a bit late to the party, but ... >> > --- rme9652.c.ORIGINAL Thu Dec 18 23:43:36 2003 >> > +++ rme9652.c Thu Dec 18 23:45:12 2003 >> > @@ -1618,7 +1618,6 @@ >> > RME9652_SPDIF_RATE("IEC958 Sample Rate", 0), >> > RME9652_ADAT_SYNC("ADAT1 Sync Check", 0, 0), >> > RME9652_ADAT_SYNC("A

Re: [Alsa-devel] Why does Alsa sometimes not find the HDSP 9652?

>Justin, > I'm running Alsa-1.0.0rc2. How much more up to date could I be? > > Also, this is an HDSP 9652 which has the firmware on the board. Why >is a firmware loader required at all? its not. jaroslav used that phrase because the bug manifested itself most clearly when loading firmware. it

[Alsa-devel] intel ICH sample rate

i've been getting my laptop with an ICH soundchip up to speed, and i just noticed for the first time yesterday that ALSA fails to get the speed to the rate that JACK requests. a quick google reveals that the OSS drivers only support 1 h/w rate, but there are suggestions that the ALSA driver works b

Re: [Alsa-devel] intel ICH sample rate

>i've been getting my laptop with an ICH soundchip up to speed, and i >just noticed for the first time yesterday that ALSA fails to get the >speed to the rate that JACK requests. a quick google reveals that the >OSS drivers only support 1 h/w rate, but there are suggestions that >the ALSA driver wo

Re: [Alsa-devel] intel ICH sample rate

>yOn Sat, 27 Dec 2003, Paul Davis wrote: > >> >i've been getting my laptop with an ICH soundchip up to speed, and i >> >just noticed for the first time yesterday that ALSA fails to get the >> >speed to the rate that JACK requests. a quick google reveals that

Re: [Alsa-devel] intel ICH sample rate

>meanwhile, i have found that the plughw layer doesn't work with JACK >anymore. it appears that any attempt to set the period size fails. any >ideas about that? to clarify: any attempt to set the period size if the SR is not 48kHz will fail. --p -

Re: [Alsa-devel] Re: (Fwd) ALSA related comments - please correct [wulfram-26284]

>> We have been unable to find a way to tell ALSA, through >> snd_pcm_mmap_begin(), where we want to write data when using the mmap >> api. OSS doesn't have this restriction and this is the only documented >> way we can see to support sound engines which mix in new sounds using >> looping buffe

Re: [Alsa-devel] Re: (Fwd) ALSA related comments - please correct [wulfram-26284]

>although i agree that from a pragmatic perspective, it would be good >to understand how to use ALSA to do this. > >however, this model of audio programming is not portable, and has >gotten people into trouble before, not just under Linux. > >making the assumption that direct access at all times to

Re: [Alsa-devel] Re: (Fwd) ALSA related comments - please correct [wulfram-26284]

>That kind of argument would just corroborate the TransGaming report that >ALSA is no good overhead-wise, which is probably not what the ALSA >developers wish to do here. i wasn't talking about ALSA. i was talking about audio hardware and programming models in general. ALSA will allow pretty much

Re: [Alsa-devel] DMIX and capture stream

>I'm working on changing DMIX to allow clients to open the capture stream. i don't get it. dmix is for playback, not capture. what would be the semantics of this? --p --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expe

Re: [Alsa-devel] Jack-Alsa plugin - problems

>However, trying to use either xmms, mplayer or mythtv with the same alsa >device just seems to leave the app "hanging" and not doing anything, and >attempts to fastforward in mplayer and mythtv (which presumably causes the >alsa layer in each app to try and pause then reopen the sound layer) cause

Re: [Alsa-devel] HDSP as normal user.

>Using latest cvs I am unable to run the hdsp as a normal user. It works >as root user however. > >Any ideas for fixing this? more specifics about what doesn't work would be helpful. --- This SF.net email is sponsored by: IBM Linux Tutorials.

Re: [Alsa-devel] DMIX and capture stream

>I have application A that needs to open payback and capture streams >because it's a two-way communications program. Application B is a game >that uses playback only. I want to use these both at the same time. but i don't think you can do this with OSS. why should ALSA's OSS emulation make it

Re: [Alsa-devel] DMIX and capture stream

>> >I have application A that needs to open payback and capture streams >> >because it's a two-way communications program. Application B is a game >> >that uses playback only. I want to use these both at the same time. >> >> but i don't think you can do this with OSS. why should ALSA's OSS >>

Re: [Alsa-devel] Moving from OSS to ALSA

> I am currently looking into rewriting our current OSS sound routines to nat >ive ALSA, as it seems OSS will invariably be phased out now that the ALSA driv >er is distrubuted with the Linux kernel, plus ALSA seems to have a great numbe >r of benefits for us. > > Our current sound routines per

Re: [Alsa-devel] Moving from OSS to ALSA

>Yes, we're aware that our APIs are rather too much complicated for simple >applications. We are designing the very simple (current name ordinary) >APIs to let more developers join us. But as Kai noticed, these APIs will >be a bit limited, so they won't be intended for more complex applications.

Re: [Alsa-devel] hdsp problem

>it's not working on my system (i tried 64, 128, 256) ... but playing then i guess there is more than one problem. i would also recommend checking into whatever is sharing the interrupt that the hdsp is on. on my laptop, way too many things are on IRQ10 (USB, CardBus, Wifi, HDSP). this seems hard

Re: [Alsa-devel] HDSP 9632 driver and expansion cards

>Anyone using the latest RME HDSP 9632 driver in ALSA, while also using >the expansion cards? I mean, the newer AI4S-192 and/or AO4S-192 which >are required to get the 192kHz sampling on all analogs. > >Do the latest expansion cards (192kHz) work with the latest ALSA driver? i doubt it. RME have n

Re: [Alsa-devel] HDSP 9632 driver and expansion cards

>I have a few usability comments with regards to the drivers that I would >like to share, will draft a fuller email later, but basically I am using it >as a hifi input for music, nothing else, but I'm frequently getting very >jittery & broken up audio (guessing that the default alsa buffer/latency

Re: [Alsa-devel] Creamware Noah, snd-usb-audio capable?

>Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber0 > bAlternateSetting 0 > bNumEndpoints 6 > bInterfaceClass 255 Vendor Specific Class ^^^

Re: [Alsa-devel] Re: The obsolence of OSS, Was: big smile

>I don't think so. If an sound app is swapped out or another app is doing >intensive disk IO we could observe - hear - the difference. and how can OSS help with that? ok, so we know that non-SCHED_FIFO apps (and occasionally, even them) can be delayed by kernel-side issues. but not keeping up with

Re: [Alsa-devel] Re: The obsolence of OSS, Was: big smiley

>On Wed, Feb 25, 2004 at 09:17:54AM -0500, Paul Davis wrote: >> There are only 2 differences associated with running the code you are >> talking about in the kernel: >> >> a) it runs deterministically in interrupt context >> b) it avoids a context swit

Re: [Alsa-devel] Re: The obsolence of OSS, Was: big smiley

>The ideal scheduler for realtime apps would be one that has an api that >allows for a call like "schedule me at exactly 10ms intervals+-1ms". no, thats not true. the system clock does not run in sync with the sample clock. the drift in this would become noticeable in a few minutes. the only ti

Re: [Alsa-devel] Re: The obsolence of OSS, Was: big smiley

>It would still be nice to have a system clock based interval process for >applications that require activity at specific intervals, but are not to >do with sound or video. i'd be interested to see a realistic usage case. its mostly related to RT devices of some kind, most of which provide their

Re: [Alsa-devel] Re: The obsolence of OSS, Was: big smiley

>It would still be nice to have a system clock based interval process for >applications that require activity at specific intervals, but are not to >do with sound or video. have any actual use cases? >An audio hardware interrupt can interrupt any process at any time. >Is there already a procedu

<    1   2   3   4   5   6   7   8   >