headers
Frank Barknecht | 1 Mar 2004 01:10
Favicon

Re: Soundcard matrix: removing some M-Audio USB devices

Hallo,
James Courtier-Dutton hat gesagt: // James Courtier-Dutton wrote:

> You will be lucky to find any sound card complying with the USB Audio 
> spec, as the spec is written so badly.

This is the USB spec I'm referring, not the USB AUDIO spec. Those
M-Audio devices aren't even recognized as being USB devices by the
kernel.

ciao
--

-- 
 Frank Barknecht                               _ ______footils.org__

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
Permalink | Reply | 2 comments |
headers
Ann Patterson | 1 Mar 2004 03:18
Picon
Favicon

M-Audio Revolution and MythTV

I installed a M-Audio Revolution 7.1 (snd-ice1724) in my mythtv box. I
had mythtv working fine with the machine's onboard sound (snd-trident)
using OSS emulation. The revo works correctly for things like xine,
mplayer, aplay (of course), play, etc. In mythtv, however, I get no
sound. 

I dug into the mythtv code, and found that it is doing a call to
ioctl(audiofd, SNDCTL_DSP_GETOSPACE, &info) and using the info.bytes
value that is returned to determine whether or not to write to the card.
The first call to SNDCTL_DSP_GETOSPACE appears to return a reasonable
number, but from that point, the numbers returned are all over the
place, and are often negative. So, mythtv, of course, won't write to the
card. I find that if I comment out the code that checks the values
returned from GETOSPACE, I get sound, but it is out of sync with the
video (sound slightly behind video).

I'm using the dmix plugin, if that matters, but I got the same results
without the plugin.

I'm willing to debug this further, but I've not done anything with alsa
or soundcards before, so I need a bit of help in determining where to
look.

--

-- 

Ann P.

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
(Continue reading)

Permalink | Reply | 3 comments |
headers
Doug McLain | 1 Mar 2004 08:21
Picon

return value of snd_pcm_hw_params_set_rate_near

According to the alsa documentation, the return value of 
snd_hw_params_set_rate_near is the 'approximate chosen rate', and the 
3rd arg being type 'int'.  The two tutorials at the documentation 
section of the alsa-project website both hold true to this with code like:

exact_rate = snd_pcm_hw_params_set_rate_near(pcm_handle, hwparams, rate, &dir);
    if (dir != 0) {
      fprintf(stderr, "The rate %d Hz is not supported by your hardware.\n 
                       ==> Using %d Hz instead.\n", rate, exact_rate);
    }

After unsuccesful attempts at using this function this way (I'm learning 
linux audio software devel starting with alsa drivers and user 
interface), I went into the aplay source and found the version that 
tests a before and after version of arg 3 (which is a pointer to int 
that gets changed to the result rate by the function) and tests the 
return only for err. I assume this function changed?  Im at the learning 
stage so I'm probably stating the obvious, but when your new sometimes 
reassurance from someone that knows helps.  Is the documentaion just 
behind, or did this slip by unnoticed?  Curious...

---

http://nostar.isa-geek.com

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jaroslav Kysela | 1 Mar 2004 09:17
Picon

Re: M-Audio Revolution and MythTV

On Sun, 29 Feb 2004, Ann Patterson wrote:

> I installed a M-Audio Revolution 7.1 (snd-ice1724) in my mythtv box. I
> had mythtv working fine with the machine's onboard sound (snd-trident)
> using OSS emulation. The revo works correctly for things like xine,
> mplayer, aplay (of course), play, etc. In mythtv, however, I get no
> sound. 
> 
> I dug into the mythtv code, and found that it is doing a call to
> ioctl(audiofd, SNDCTL_DSP_GETOSPACE, &info) and using the info.bytes
> value that is returned to determine whether or not to write to the card.
> The first call to SNDCTL_DSP_GETOSPACE appears to return a reasonable
> number, but from that point, the numbers returned are all over the
> place, and are often negative. So, mythtv, of course, won't write to the
> card. I find that if I comment out the code that checks the values
> returned from GETOSPACE, I get sound, but it is out of sync with the
> video (sound slightly behind video).
> 
> I'm using the dmix plugin, if that matters, but I got the same results
> without the plugin.
> 
> I'm willing to debug this further, but I've not done anything with alsa
> or soundcards before, so I need a bit of help in determining where to
> look.

Can you write a nice small test code which shows this problem? You may 
modify code in alsa-oss/test/osstest.c .

						Jaroslav
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jaroslav Kysela | 1 Mar 2004 09:24
Picon

Re: return value of snd_pcm_hw_params_set_rate_near

On Mon, 1 Mar 2004, Doug McLain wrote:

> According to the alsa documentation, the return value of 
> snd_hw_params_set_rate_near is the 'approximate chosen rate', and the 
> 3rd arg being type 'int'.  The two tutorials at the documentation 
> section of the alsa-project website both hold true to this with code like:
> 
> exact_rate = snd_pcm_hw_params_set_rate_near(pcm_handle, hwparams, rate, &dir);
>     if (dir != 0) {
>       fprintf(stderr, "The rate %d Hz is not supported by your hardware.\n 
>                        ==> Using %d Hz instead.\n", rate, exact_rate);
>     }
> 
> 
> 
> After unsuccesful attempts at using this function this way (I'm learning 
> linux audio software devel starting with alsa drivers and user 
> interface), I went into the aplay source and found the version that 
> tests a before and after version of arg 3 (which is a pointer to int 
> that gets changed to the result rate by the function) and tests the 
> return only for err. I assume this function changed?  Im at the learning 
> stage so I'm probably stating the obvious, but when your new sometimes 
> reassurance from someone that knows helps.  Is the documentaion just 
> behind, or did this slip by unnoticed?  Curious...

Yes, the new functions returns value in function parameter not result.

Can you post me URL on the ALSA website, where this information is not 
updated?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Doug McLain | 1 Mar 2004 09:49
Picon

Re: return value of snd_pcm_hw_params_set_rate_near

http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.html#a58

Thanks for the reply...

P.S.  I was mistaken, the doc does in fact define arg 3 as 'pointer to 
int' and describes the action.  The return value is the only problem.

Jaroslav Kysela wrote:

>On Mon, 1 Mar 2004, Doug McLain wrote:
>
>  
>
>>According to the alsa documentation, the return value of 
>>snd_hw_params_set_rate_near is the 'approximate chosen rate', and the 
>>3rd arg being type 'int'.  The two tutorials at the documentation 
>>section of the alsa-project website both hold true to this with code like:
>>
>>exact_rate = snd_pcm_hw_params_set_rate_near(pcm_handle, hwparams, rate, &dir);
>>    if (dir != 0) {
>>      fprintf(stderr, "The rate %d Hz is not supported by your hardware.\n 
>>                       ==> Using %d Hz instead.\n", rate, exact_rate);
>>    }
>>
>>
>>
>>After unsuccesful attempts at using this function this way (I'm learning 
>>linux audio software devel starting with alsa drivers and user 
>>interface), I went into the aplay source and found the version that 
>>tests a before and after version of arg 3 (which is a pointer to int
(Continue reading)

Permalink | Reply | 0 comments |
headers
Måns Rullgård | 1 Mar 2004 10:21
Picon
Picon
Favicon

Re: return value of snd_pcm_hw_params_set_rate_near

Doug McLain <nostar <at> comcast.net> writes:

> According to the alsa documentation, the return value of
> snd_hw_params_set_rate_near is the 'approximate chosen rate', and the
> 3rd arg being type 'int'.  The two tutorials at the documentation
> section of the alsa-project website both hold true to this with code
> like:
>
> exact_rate = snd_pcm_hw_params_set_rate_near(pcm_handle, hwparams, rate, &dir);
>     if (dir != 0) {
>       fprintf(stderr, "The rate %d Hz is not supported by your
>       hardware.\n                      ==> Using %d Hz instead.\n",
>       rate, exact_rate);
>     }
>
> After unsuccesful attempts at using this function this way (I'm
> learning linux audio software devel starting with alsa drivers and
> user interface), I went into the aplay source and found the version
> that tests a before and after version of arg 3 (which is a pointer to
> int that gets changed to the result rate by the function) and tests
> the return only for err. I assume this function changed?  Im at the
> learning stage so I'm probably stating the obvious, but when your new
> sometimes reassurance from someone that knows helps.  Is the
> documentaion just behind, or did this slip by unnoticed?  Curious...

The function was changed some time ago, along with a few other similar
cases.

--

-- 
Måns Rullgård
(Continue reading)

Permalink | Reply | 0 comments |
headers
Clemens Ladisch | 1 Mar 2004 13:52
Picon
Gravatar

Re: Scatter Gather

Manuel Jander wrote:
> AFAIK, it seems that when using a scatter gather buffer, not every
> period is located inside of a page. ...
> The problem is that a DMA transfer can not go accross 2 different pages.
> On Aureal hardware, even on contiguous buffers this causes all sort of
> odd problems. Each DMA chunk must be on the same page.
> ...
> That means that i would have to split each period that crosses a page
> boundary into 2 DMA chunks, with all the complications involved because
> of irregular sizes, offsets... ARghhh!

Yes.  Every driver using SG must do this.  Look into bt87x.c or
via82xx.c for examples.

> I could just leave the period size as a power of 2, on that way, a
> period would never cross any page boundary, but most ALSA programs are
> too picky to accept that kind of restrictions in most cases.

Devices like usb and ymfpci have a fixed period size, but their
drivers emulate arbitrary period sizes.

Regards,
Clemens

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
(Continue reading)

Permalink | Reply | 4 comments |
headers
Clemens Ladisch | 1 Mar 2004 14:02
Picon
Gravatar

Re: setting ppq problems

jacqueslen <at> sympatico.ca wrote:
> I'm trying to set my ppq on my queue, so I do this:
>
>     snd_seq_queue_tempo_t *qt;
>     snd_seq_queue_tempo_alloca(&qt);
>     snd_seq_queue_tempo_set_ppq(qt, ppq);
>     return snd_seq_set_queue_tempo(seq, id, qt);

> that returns -22, what does that mean?

snd_strerror(-22) = "Invalid argument"

A snd_seq_queue_tempo_t container contains various parameters, so you
should set all fields to valid values (or get the current values first
with snd_seq_get_queue_tempo).

> Also, where can I found out what the members of
> snd_seq_queue_tempo_t are, I can't seem to find it anywhere!

The snd_seq_get/set_queue_tempo_xxx functions are listed on this page:
http://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_queue.html

HTH
Clemens

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
(Continue reading)

Permalink | Reply | 0 comments |
headers
Maggio | 1 Mar 2004 15:00
Picon

DXS broken with some cards in 1.0.X in module snd-via82xx?

Hi ,

I was just wondering if the DXS support in 1.0.X has broken the 
DXS_SUPPORT=1 with some cards .

I have an Abit KV7 Motherboard , and I use snd-via82xx for sound .

I use this module from the version "0.9.8" , and I've never had any 
problems in enabling "dxs_support=1" with the 0.9.X series of the 
drivers , yesterday , by trying 1.0.2c and today the 1.0.3 versions of 
the kernel modules , I've noticed that ALSA doesn't work anymore with 
DXS_SUPPORT=1 , because the sound is garbled  , and I can only use DXS 
with DXS_SUPPORT=4 .

What's up?

Thanks

Marcello

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
Permalink | Reply | 4 comments |

Gmane