Jaroslav Kysela wrote:
>
> On Thu, 1 Nov 2001, Abramo Bagnara wrote:
>
> >
> > I have to partially disagree, nothing inhibits to do:
> >
> > frames = buffer_size;
> > snd_pcm_mmap_begin(pcm, areas, &offset, &frames);
> >
> > and then reduce the number of frames to call snd_pcm_mmap_commit with.
On Sat, 27 Oct 2001 20:53, stef wrote:
> Allan Klinbail wrote:
> > Earlier in the year I posted notices about the mtpav driver. Specifically
> > 2 problems ...a). no input being recognised. b) output only works
> > when one input port is selected.
> >
> > I finally got the cvs version of alsa
I've been experimenting with recording at >16 bit depths (Midiman Audiophile
and current ALSA CVS).
Since 24-bit files are a right-royal-pain and the ALSA hw device for ice1712
uses a format of S32_LE, I've been recording to 32-bit .wav files, using both
arecord and snd (built with native alsa
>I've been experimenting with recording at >16 bit depths (Midiman Audiophile
>and current ALSA CVS).
been doing it for a couple of years now :)
>Since 24-bit files are a right-royal-pain and the ALSA hw device for ice1712
>uses a format of S32_LE, I've been recording to 32-bit .wav files, usi
On Thursday 01 November 2001 12:07, Paul Davis wrote:
> >I've been experimenting with recording at >16 bit depths (Midiman
> > Audiophile and current ALSA CVS).
>
> been doing it for a couple of years now :)
I wasn't claiming this was anything new, just that I've not done much before,
since on m
>> the hw params include information on both the sample bit width and
>> `msbits', which tell you how (for example) the 24 bit
>> data is packed into 32 bits.
>
>It is however not clear to me that this is encoded in the header of a normal
>WAV file (unless bits_per_sample should be 24 for snd's c
Son of Zev wrote:
> Using all available tools provided by ALSA my system does not see any input
> from my MOTU MTPAV
cat /proc/asound/seq/clients should show 19 MTP ports, and
cat /proc/asound/card0/midi0 should show 19 inputs and 19 outputs,
assuming the mtpav is card0.
Input worked for me bot
Paul Davis wrote:
>
> >Does anyone on this list know how to setup .asoundrc to allow an app
> >to monitor the audio ouput on ANY pcm device/subdevice like in the
> >0.5.x tree? (snd_pcm_loopback)
>
> IIRC, there is no loopback API in 0.9x. I could be wrong though.
>
> personally, I think that
please take this with a grain of salt, and my apologies offered if i
come over too strong. i beg you to read on and think twice about it,
i'm trying to help even if i may not find the right words.
personally at this particular point i find the documentation rather
obscures than explains the matte
>Yes, while we have the mmap_begin function limiting the transfer count and
>application knows how many samples should be filled, the reducing the
>counf of channel is really not necessary. I think that it would be better
>to avoid to do this by programmers, because we can use the mmap_commit
>siz
>No, NO...
>
>Never do this mistake, you cannot use mmap_begin result to know how many
>frames are available: it simply does not work with non HW PCM.
>
>You *have* to use snd_pcm_avail_update() for that.
I was simplifying my loop for pedagogical purposes. Of course I use
snd_pcm_avail_update() i
> avail = snd_pcm_avail_update(pcm);
> while (avail > 0) {
> frames = min(avail, block_size);
> snd_pcm_mmap_begin(pcm, areas, &offset, &frames);
> process(frames);
> snd_pcm_mmap_commit(pcm, offset, frames);
> avail
abramo,
honestly i find it a little unfair to correct me on a sidenote and
completely disregard the true intention of my mail (at least that's
the impression i got).
all i am saying is the documentation is not giving the ALSA programmer
a clear picture of what which function is used for. the i
Paul Davis wrote:
>
> > avail = snd_pcm_avail_update(pcm);
> > while (avail > 0) {
> > frames = min(avail, block_size);
> > snd_pcm_mmap_begin(pcm, areas, &offset, &frames);
> > process(frames);
> > snd_pcm_mmap_commit(pcm, offse
Today Abramo Bagnara wrote:
>Paul Davis wrote:
>>
>> > avail = snd_pcm_avail_update(pcm);
>> > while (avail > 0) {
>> > frames = min(avail, block_size);
>> > snd_pcm_mmap_begin(pcm, areas, &offset, &frames);
>> > process(frames);
>> >
> On Mon, Oct 29, 2001 at 07:44:22AM +0100, Jaroslav Kysela wrote:
>>
>> The driver is being developed by Haroldo Gamal and Marek Peteraj (see the
>> CC list). I have some alpha code from them (I don't know, if it is stable
>> enought to include it to CVS for more public audience).
>
> I have a
>Jack has some infrastructure (cvs, mailing lists, home page,
>documentation, etc.) that permits to track its evolution?
it should have all these things. alas, with the current availability
of time, plus the impending uncertain future of SourceForge, its not
clear how best to go about this. Are y
Paul Davis wrote:
>
> >Jack has some infrastructure (cvs, mailing lists, home page,
> >documentation, etc.) that permits to track its evolution?
>
> it should have all these things. alas, with the current availability
> of time, plus the impending uncertain future of SourceForge, its not
> clear
Hi
I'm new to this list, and new to Linux. I have worked with Unix
device drivers, but not Linux.
I have an emagic AMT 8 midi patch bay. (Similar to Unitor 8).
I've never gotten this to work in _indoze (can I speak that word on
this list?) despite much shenanigans, so I'm wondering
1) Is an
[EMAIL PROTECTED] wrote:
> I have an emagic AMT 8 midi patch bay. (Similar to Unitor 8).
I have this one, too. Works great with our apple macintosh.
> 1) Is anyone working on a driver for this?
Don't know. But it would be great.
> 2) If not, is there a FAQ on how to approach a manufacturer
On Thu, 1 Nov 2001, stef wrote:
> [EMAIL PROTECTED] wrote:
>
> > I have an emagic AMT 8 midi patch bay. (Similar to Unitor 8).
>
> I have this one, too. Works great with our apple macintosh.
>
> > 1) Is anyone working on a driver for this?
>
> Don't know. But it would be great.
>
> > 2) If not
Today Manush Dodunekov wrote:
>On Thu, 1 Nov 2001, stef wrote:
>
>> [EMAIL PROTECTED] wrote:
>>
>> > I have an emagic AMT 8 midi patch bay. (Similar to Unitor 8).
>>
>> I have this one, too. Works great with our apple macintosh.
>>
>> > 1) Is anyone working on a driver for this?
>>
>> Don't kno
>It would be very interesting to see ALSA implementing device-specific
>hardware queuing for multiport MIDI devices - lot's of the "professional"
>ones have it nowadays. With different top-secret protocols of course.
yes, i suspect its going to cause as much disruption to ALSA's MIDI
side as the
On Thu, 1 Nov 2001, martijn sipkema wrote:
> > On Thu, 1 Nov 2001, stef wrote:
> >
> > > [EMAIL PROTECTED] wrote:
> > >
> > > > I have an emagic AMT 8 midi patch bay. (Similar to Unitor 8).
> > >
> > > I have this one, too. Works great with our apple macintosh.
> > >
> > > > 1) Is anyone workin
>Does anyone on this list know how to setup .asoundrc to allow an app
>to monitor the audio ouput on ANY pcm device/subdevice like in the
>0.5.x tree? (snd_pcm_loopback)
IIRC, there is no loopback API in 0.9x. I could be wrong though.
personally, I think that if you think far enough ahead, you
Does anyone on this list know how to setup .asoundrc to allow an app to monitor
the audio ouput on ANY pcm device/subdevice like in the 0.5.x tree?
(snd_pcm_loopback)
As 0.9.x matures, I want my applications that used pcm_loopback to be ported to
use the much more robust 0.9.x API. I'd thought
26 matches
Mail list logo
