13 May
2016
13 May
'16
6:12 p.m.
Hi.
I've been sinking lots of time in trying to get ALSA to work with a
SGTL5000 (Teensy Audio Adapter) in Raspbian on a Raspberry Pi 3. I have the
complete documentation for how to manually set up the audio chip, and
sufficient documentation on how to manually set up the Pi's ARM I2S
peripheral. The ALSA solution is generalized for any kind of hardware you
could want, is something I don't really want to know, at all, in my life,
and seems just far too complex when I have detailed guides for both the
audio chip and the CPU. The one combination of ALSA platform, machine and
codec drivers that I've managed to get sound from plays more than 2x too
fast and will not open with JACK.
So, I'm reading about the JACK API, wondering about simply writing a C
program to configure and write to the Pi's built-in I2S FIFOs, without even
telling ALSA that I'm doing it; but I see that all JACK clients should use
callback functions. Still, audio input from JACK into a program using the
API is a regular thing, right? So how complicated might it be to set up
such a client that gets audio input from JACK and writes that to the chip's
I2S FIFO? My timing will be controlled by the audio chip, the Pi chip will
be a slave to it. So as long as my program writes to the transmit FIFO fast
enough, and waits if the FIFO is full, I think I don't need to worry about
synchronizing JACK exactly to the audio chip's clock... right?
I'm just a little fuzzy on this timing part.
Thanks for any clarification.
-Chuckk
--
http://www.badmuthahubbard.com
13 May
13 May
6:41 p.m.
New subject: [Jack-Devel] Implement a driver as a writable client?
You can't do duplex properly as a client. The main difference between a
JACK "driver" (aka "backend") and a client is that a driver consists
of two
halves. One is executed at the start of a process cycle, to collect data
from the hardware; the other is executed at the end of a process cycle, to
deliver data to the hardware.
If you're not doing duplex, you can do whatever you want in a client, but
keep in mind that it cannot block, meaning that you basically have to
shuffle the data to/from another thread that actually interacts with the
hardware.
On Fri, May 13, 2016 at 7:12 PM, Chuckk Hubbard <badmuthahubbard(a)gmail.com>
wrote:
Hi.
I've been sinking lots of time in trying to get ALSA to work with a
SGTL5000 (Teensy Audio Adapter) in Raspbian on a Raspberry Pi 3. I have the
complete documentation for how to manually set up the audio chip, and
sufficient documentation on how to manually set up the Pi's ARM I2S
peripheral. The ALSA solution is generalized for any kind of hardware you
could want, is something I don't really want to know, at all, in my life,
and seems just far too complex when I have detailed guides for both the
audio chip and the CPU. The one combination of ALSA platform, machine and
codec drivers that I've managed to get sound from plays more than 2x too
fast and will not open with JACK.
So, I'm reading about the JACK API, wondering about simply writing a C
program to configure and write to the Pi's built-in I2S FIFOs, without even
telling ALSA that I'm doing it; but I see that all JACK clients should use
callback functions. Still, audio input from JACK into a program using the
API is a regular thing, right? So how complicated might it be to set up
such a client that gets audio input from JACK and writes that to the chip's
I2S FIFO? My timing will be controlled by the audio chip, the Pi chip will
be a slave to it. So as long as my program writes to the transmit FIFO fast
enough, and waits if the FIFO is full, I think I don't need to worry about
synchronizing JACK exactly to the audio chip's clock... right?
I'm just a little fuzzy on this timing part.
Thanks for any clarification.
-Chuckk
--
http://www.badmuthahubbard.com
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
14 May
14 May
6:12 p.m.
New subject: [Jack-Devel] Implement a driver as a writable client?
Thanks for the info, Paul.
So, are you basically saying I need an extra buffer? A client takes audio
input from the JACK server and writes it to a buffer, and I have to
manually tweak the size of that buffer to avoid over- or underruns, and
another thread writes from that buffer to the hardware I2S FIFO whenever
it's writable? If I understand the implications of clients being unable to
block as you say, the audio generation programs won't ever wait for my
improvised "driver"... but I'm not sure if I get why that's something
to
worry about.
-Chuckk
On Sat, May 14, 2016 at 2:41 AM, Paul Davis <paul(a)linuxaudiosystems.com>
wrote:
You can't do duplex properly as a client. The main
difference between a
JACK "driver" (aka "backend") and a client is that a driver consists
of two
halves. One is executed at the start of a process cycle, to collect data
from the hardware; the other is executed at the end of a process cycle, to
deliver data to the hardware.
If you're not doing duplex, you can do whatever you want in a client, but
keep in mind that it cannot block, meaning that you basically have to
shuffle the data to/from another thread that actually interacts with the
hardware.
On Fri, May 13, 2016 at 7:12 PM, Chuckk Hubbard <badmuthahubbard(a)gmail.com
--
http://www.badmuthahubbard.com
wrote:
Hi.
I've been sinking lots of time in trying to get ALSA to work with a
SGTL5000 (Teensy Audio Adapter) in Raspbian on a Raspberry Pi 3. I have the
complete documentation for how to manually set up the audio chip, and
sufficient documentation on how to manually set up the Pi's ARM I2S
peripheral. The ALSA solution is generalized for any kind of hardware you
could want, is something I don't really want to know, at all, in my life,
and seems just far too complex when I have detailed guides for both the
audio chip and the CPU. The one combination of ALSA platform, machine and
codec drivers that I've managed to get sound from plays more than 2x too
fast and will not open with JACK.
So, I'm reading about the JACK API, wondering about simply writing a C
program to configure and write to the Pi's built-in I2S FIFOs, without even
telling ALSA that I'm doing it; but I see that all JACK clients should use
callback functions. Still, audio input from JACK into a program using the
API is a regular thing, right? So how complicated might it be to set up
such a client that gets audio input from JACK and writes that to the chip's
I2S FIFO? My timing will be controlled by the audio chip, the Pi chip will
be a slave to it. So as long as my program writes to the transmit FIFO fast
enough, and waits if the FIFO is full, I think I don't need to worry about
synchronizing JACK exactly to the audio chip's clock... right?
I'm just a little fuzzy on this timing part.
Thanks for any clarification.
-Chuckk
--
http://www.badmuthahubbard.com
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
15 May
15 May
1:17 a.m.
New subject: [Jack-Devel] Implement a driver as a writable client?
On Sat, May 14, 2016 at 1:41 AM, Paul Davis <paul(a)linuxaudiosystems.com>
wrote:
You can't do duplex properly as a client. The main
difference between a
JACK "driver" (aka "backend") and a client is that a driver consists
of two
halves. One is executed at the start of a process cycle, to collect data
from the hardware; the other is executed at the end of a process cycle, to
deliver data to the hardware.
But why not just use two clients in the same program to achieve the same
thing?
7:13 a.m.
New subject: [Jack-Devel] Implement a driver as a writable client?
Drivers are in-process, not out-of-process like most clients.
You could write two in-process clients. You could also write slave drivers,
which are like backends but different in subtle ways.
On Sun, May 15, 2016 at 2:17 AM, Kjetil Matheussen <k.s.matheussen(a)gmail.com
wrote:
>
>
> On Sat, May 14, 2016 at 1:41 AM, Paul Davis <paul(a)linuxaudiosystems.com>
wrote:
>
>> You can't do duplex properly as a client. The main difference between a
>> JACK "driver" (aka "backend") and a client is that a driver
consists of two
>> halves. One is executed at the start of a process cycle, to collect data
>> from the hardware; the other is executed at the end of a process cycle, to
>> deliver data to the hardware.
>>
>>
> But why not just use two clients in the same program to achieve the same
> thing?
>
>
>
12:58 p.m.
New subject: [Jack-Devel] Implement a driver as a writable client?
On Sun, May 15, 2016 7:13 am, Paul Davis wrote:
Drivers are in-process, not out-of-process like most
clients.
You could write two in-process clients. You could also write slave
drivers, which are like backends but different in subtle ways.
I'm not sure why everyone is dancing around the obvious answer: what the
original poster seems to want is a new backend. Is that really difficult?
It sounds like he wants something that is just very simple, tailored
exactly to the hardware he has, without some of the complexity that comes
along with ALSA. Is that an unreasonable thing to work on?
--
Chris Caudle
3:04 p.m.
New subject: [Jack-Devel] Implement a driver as a writable client?
the infrastructure for backends is a bit more complex than for clients. but
otherwise, it's a perfectly reasonable thing to work on.... but ... not
portable across JACK implementations (which may or may not be important).
On Sun, May 15, 2016 at 1:57 PM, Chris Caudle <chris(a)chriscaudle.org> wrote:
On Sun, May 15, 2016 7:13 am, Paul Davis wrote:
Drivers are in-process, not out-of-process like
most clients.
You could write two in-process clients. You could also write slave
drivers, which are like backends but different in subtle ways.
I'm not sure why everyone is dancing around the obvious answer: what the
original poster seems to want is a new backend. Is that really difficult?
It sounds like he wants something that is just very simple, tailored
exactly to the hardware he has, without some of the complexity that comes
along with ALSA. Is that an unreasonable thing to work on?
--
Chris Caudle
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
3174
days inactive
3176
days old
jackaudio@lists.linuxaudio.org
6 comments
4 participants
participants (4)
-
Chris Caudle -
Chuckk Hubbard -
Kjetil Matheussen -
Paul Davis