From: Florian Faber <faber@faberman.de>
To: alsa-devel@alsa-project.org
Subject: Re: RME MADIface 192 kHz problem
Date: Fri, 22 Oct 2010 11:54:36 +0200 [thread overview]
Message-ID: <4CC15F5C.3010400@faberman.de> (raw)
In-Reply-To: <s5hlj5qbngq.wl%tiwai@suse.de>
Takashi,
>>>>> What is needed to get this card running at 192 kHz?
>>>> A working driver :)
>>>>
>>>> http://wiki.linuxproaudio.org/index.php/Driver:hdspe
>>> How about posting the patches? :)
>>
>> It would be dozens/hundreds of single patches against the hdspm driver.
>
> I don't mind any number of patches if they are written logically and
> well readable.
>
>> I'd rather replace it with the version above.
>
> If it's more or less compatible with the current driver, it's fine.
> But, one bulk patch is bad. Even if you replace the driver code,
> split in a logical order, at best.
There are changes everywhere since the old driver inherited a lot of
code from the hdsp driver which in turn inherited a lot of code from
previous drivers. The code was never properly suited to support a
broader range of hardware.
I don't have the time to split up all the changes in all the different
places and if I had the time, I would rather do a complete rewrite (or
better: Finish the rewrite I started a while ago).
>> And I changed one ioctl
>> which would break compatibility - although I doubt anybody used the
>> levelmeter ioctl besides me. The version above is a 'public beta'.
> If it's a new ioctl, it's OK. We can drop the old (very likely)
> unused ioctl eventually. But using the same ioctl for different
> behavior is no go.
Ok, dropping the old one in favour of the new one.
>> If the support for the AIO/RayDAT finally works - sure. But for that I
>> still need to tell ALSA somehow that there are n buffers to use, n>2,
>> with n IRQs per buffer cycle.
> Well, actually I forget what your questions are. Please continue it
> on ML here.
>
> All other sound drivers work fine with more than two periods, so I
> don't think there is any restriction in the API side.
Ok, the problem was that the AIO/RayDAT have two modes of operation, a
'windows' mode and a 'mac' mode. In the 'windows' mode the full 16k
sample buffer is utilized and the card produces 16k/period_size IRQs
while running through the buffer. I'd need a way to tell ALSA this.
In 'mac' mode it uses a double buffering scheme but only produces one
IRQ per each double buffer walkthru. I understand that ALSA does not
support this mode of operation.
Flo
--
Machines can do the work, so people have time to think.
public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net
next prev parent reply other threads:[~2010-10-22 9:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-21 13:03 RME MADIface 192 kHz problem Fredrik Lingvall
2010-10-21 14:10 ` Florian Faber
2010-10-21 20:52 ` Takashi Iwai
2010-10-22 5:09 ` Florian Faber
2010-10-22 9:12 ` Takashi Iwai
2010-10-22 9:54 ` Florian Faber [this message]
2010-10-23 9:19 ` Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CC15F5C.3010400@faberman.de \
--to=faber@faberman.de \
--cc=alsa-devel@alsa-project.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.