Re: emu10k1 latency / capture period

Re: emu10k1 latency / capture period

[Peter Zubaj]

Hi,

>With this patch I can run JACK in capture only mode with the period size
>set as low as 128.  64 gives an error.  This is exactly the expected
>behavior: 128 frames is the lowest setting the kX ASIO driver allows.

When you dissable these constraints driver automatic sets period size
(alias capture buffer size to minimal value)

I think driver will print some asserts - check your console or logs
for it.

Peter Zubaj



====================== REKLAMA ========================
Spolocnost SUN Microsystems uviedla na trh novy server Sun Fire V20z
zalozeny procesoroch AMD Opteron.
Viac informacii najdete na : http://www.somi.sk/sun/v20z.php
=======================================================



-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: emu10k1 latency / capture period

[Takashi Iwai]

At Mon, 21 Jun 2004 10:03:28 +0200,
Peter Zubaj wrote:
> 
> Hi,
> 
> >With this patch I can run JACK in capture only mode with the period size
> >set as low as 128.  64 gives an error.  This is exactly the expected
> >behavior: 128 frames is the lowest setting the kX ASIO driver allows.
> 
> When you dissable these constraints driver automatic sets period size
> (alias capture buffer size to minimal value)
> 
> I think driver will print some asserts - check your console or logs
> for it.

Well, if the "error" means an buffer XRUN, the driver doesn't assert.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: emu10k1 latency / capture period

[Lee Revell]

On Mon, 2004-06-21 at 11:26, Takashi Iwai wrote:
> At Mon, 21 Jun 2004 10:03:28 +0200,
> Peter Zubaj wrote:
> > 
> > Hi,
> > 
> > >With this patch I can run JACK in capture only mode with the period size
> > >set as low as 128.  64 gives an error.  This is exactly the expected
> > >behavior: 128 frames is the lowest setting the kX ASIO driver allows.
> > 
> > When you dissable these constraints driver automatic sets period size
> > (alias capture buffer size to minimal value)
> > 
> > I think driver will print some asserts - check your console or logs
> > for it.
> 
> Well, if the "error" means an buffer XRUN, the driver doesn't assert.
> 

Yes, that is exactly what it does, it just XRUNS.  The patch is wrong.
I think I have figured out the right way to do it, see my reply to
Takashi.

Lee



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: emu10k1 latency / capture period

[Peter Zubaj]

Hi,

I don't well understand ALSA concepts, but I think, that minimum
period size for emu10k1 is 384.

Emu10k1 has actually 3 capture devices.
0 - standard capture, stereo 16 bit / 8000 - 48000 Hz
1 - mic capture - (implemented, not very used under ALSA) mono 16 bit
/ 8000 Hz
2 - fx capture - (implemented, not very used under ALSA) 1 - 32
channels  16 bit / 48000 Hz

All have same minimal period size, but 2 has 32 channels and then I
think it is better for low latency and multichannel recording.

Peter Zubaj
====================== REKLAMA ========================
Spolocnost SUN Microsystems uviedla na trh novy server Sun Fire V20z
zalozeny procesoroch AMD Opteron.
Viac informacii najdete na : http://www.somi.sk/sun/v20z.php
=======================================================



-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: emu10k1 latency / capture period

[Lee Revell]

Peter Zubaj wrote:

>Hi,
>
>I don't well understand ALSA concepts, but I think, that minimum
>period size for emu10k1 is 384.
>  
>
True, it is actually 512 not 384.  This still results in input to output 
latency that  is 5-10x worse
than using ASIO drivers on Windows.

>Emu10k1 has actually 3 capture devices.
>0 - standard capture, stereo 16 bit / 8000 - 48000 Hz
>1 - mic capture - (implemented, not very used under ALSA) mono 16 bit
>/ 8000 Hz
>2 - fx capture - (implemented, not very used under ALSA) 1 - 32
>channels  16 bit / 48000 Hz
>
>All have same minimal period size, but 2 has 32 channels and then I
>think it is better for low latency and multichannel recording.
>  
>
Yes, the kX ASIO drivers on Windows work this way, by mapping directly 
onto the (16 for
SBLive, 32 for Audigy) FXBus channels.  You cannot directly capture line 
or mic in, you have
to connect it to an FXBus channel and then the signal is available on 
the corresponding ASIO
device.  I would imagine that to provide low latency in an ALSA driver 
it would work the same
way.

I am starting to reach the conclusion that this will require major 
changes to the guts of the emu10k1
ALSA driver.  I would love it if some ALSA developer would correct me 
but so far my inquirues
have met with deafening silence.

To reiterate the situation:  currently the ASIO drivers for this card 
provide an order of magnitude
better latency than the ALSA driver.  I am constantly hearing claims 
that ALSA is superior to ASIO,
but no one can tell me why the ALSA drivers for this *very* common 
device provide 5-10x worse latency
than the ASIO drivers.

As I see it, this is a glaring deficiency.

Lee

>Peter Zubaj
>====================== REKLAMA ========================
>Spolocnost SUN Microsystems uviedla na trh novy server Sun Fire V20z
>zalozeny procesoroch AMD Opteron.
>Viac informacii najdete na : http://www.somi.sk/sun/v20z.php
>=======================================================
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
>Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
>Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
>REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
>_______________________________________________
>Alsa-devel mailing list
>Alsa-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/alsa-devel
>
>
>  
>



-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: emu10k1 latency / capture period

[Paul Davis]

>To reiterate the situation:  currently the ASIO drivers for this card 
>provide an order of magnitude
>better latency than the ALSA driver.  I am constantly hearing claims 
>that ALSA is superior to ASIO,
>but no one can tell me why the ALSA drivers for this *very* common 
>device provide 5-10x worse latency
>than the ASIO drivers.
>
>As I see it, this is a glaring deficiency.

as a disinterested observer, i would just note that by my
understanding, Creative have not released all the necessary
programming information on the emu10k1. i suspect that whatever is
necessary to get the period size down to the levels the ASIO driver(s)
are using is in the information that they will not release without an
NDA. 

"freedom! my freedom! you got to give for what you take!"

--p


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: emu10k1 latency / capture period

[Takashi Iwai]

At Thu, 17 Jun 2004 19:26:46 -0400,
Paul Davis wrote:
> 
> >To reiterate the situation:  currently the ASIO drivers for this card 
> >provide an order of magnitude
> >better latency than the ALSA driver.  I am constantly hearing claims 
> >that ALSA is superior to ASIO,
> >but no one can tell me why the ALSA drivers for this *very* common 
> >device provide 5-10x worse latency
> >than the ASIO drivers.
> >
> >As I see it, this is a glaring deficiency.
> 
> as a disinterested observer, i would just note that by my
> understanding, Creative have not released all the necessary
> programming information on the emu10k1. i suspect that whatever is
> necessary to get the period size down to the levels the ASIO driver(s)
> are using is in the information that they will not release without an
> NDA. 

It might be.  But my guess is that ASIO uses the playback interrupt
for capture, too.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: emu10k1 latency / capture period

[Lee Revell]

Takashi Iwai wrote:

> At Thu, 17 Jun 2004 19:26:46 -0400,
> Paul Davis wrote:
> 
>>>To reiterate the situation:  currently the ASIO drivers for this card 
>>>provide an order of magnitude
>>>better latency than the ALSA driver.  I am constantly hearing claims 
>>>that ALSA is superior to ASIO,
>>>but no one can tell me why the ALSA drivers for this *very* common 
>>>device provide 5-10x worse latency
>>>than the ASIO drivers.
>>>
>>>As I see it, this is a glaring deficiency.
>>
>>as a disinterested observer, i would just note that by my
>>understanding, Creative have not released all the necessary
>>programming information on the emu10k1. i suspect that whatever is
>>necessary to get the period size down to the levels the ASIO driver(s)
>>are using is in the information that they will not release without an
>>NDA. 
> 
> 
> It might be.  But my guess is that ASIO uses the playback interrupt
> for capture, too.
> 

Thank you, this was the idea that I had, to use the playback interrupt 
to drive the capture.  I was hoping someone with in-depth knowledge of 
ALSA would agree.

Is there another ALSA driver that provides an example of this kind of 
design?  I am pretty new to hacking device drivers and an example would 
be helpful, if one is available.

P.S. Here is some background for people who are familiar with the 
emu10k1 hardware but don't use Windows or the kX drivers, I think there 
are a few on this list: The kX ASIO driver maps each FXBus channel onto 
an ASIO input and output port.  In order to do low latency/multichannel 
recording, you have to use the DSP manager to connect one of the 
physical inputs or outputs to an FXBus channel, then your ASIO app can 
read or write to that channel.

I think we only need to be concerned with the FXBus capture/playback device.

Lee


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: emu10k1 latency / capture period

[Lee Revell]

On Fri, 2004-06-18 at 05:33, Takashi Iwai wrote:

> But my guess is that ASIO uses the playback interrupt
> for capture, too.
> 

A few thing I noticed looking at the code is that the FXBus 
channels are only available as a playback device.  Shouldn't 
these also be capture devices?  This implies that the FXBus 
channels cannot be used for multichannel recording.  Is this 
correct?

Maybe modifying the driver to expose the FXBus channels as capture
devices is all that is needed.  This is really how the hardware 
works - the channels act as buses, so it's simultaneously a playback 
and a capture device.

rlrevell@debian:$ cat /proc/asound/pcm
00-00: emu10k1 : EMU10K1 : playback 32 : capture 1
00-01: emu10k1 mic : EMU10K1 MIC : capture 1
00-02: emu10k1 efx : EMU10K1 EFX : capture 1
00-03: emu10k1 : EMU10K1 FX8010 : playback 8

I also noticed that the driver only seems to be aware of 16 FXBus
channels - the Audigy has 32.  This I am going to take a shot at fixing
myself.

Lee



-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

emu10k1 latency / capture period

[Lee Revell]

Hey,

I am having a problem with the emu10k1 driver where I am unable to set
the capture period lower than 512.  The result is that the lowest
achievable input to output latency is in the neighborhood of 40ms.

I have tried with several different ALSA versions, from 0.9 through the 
latest CVS as of yesterday.

Here is the output from running the 'latency' test program from
alsa-lib.

debian:/usr/src/alsa-cvs/alsa-lib/test# ./latency -m 1024 -M 1024  -t 1
-p
Scheduler set to Round Robin with priority 99...
Playback device is hw:0,0
Capture device is hw:0,0
Parameters are 22050Hz, S16_LE, 2 channels, non-blocking mode
Wanted tick time: 1us, poll mode: yes
Loop limit is 661500 frames, minimum latency = 1024, maximum latency =
1024
Hardware PCM card 0 'Sound Blaster Audigy2' device 0 subdevice 0

Its setup is:
stream       : PLAYBACK
access       : RW_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 2
rate         : 22050
exact rate   : 22050 (22050/1)
msbits       : 16
buffer_size  : 1024
period_size  : 512
period_time  : 23219
tick_time    : 1000
tstamp_mode  : NONE
period_step  : 1
sleep_min    : 1
avail_min    : 16
xfer_align   : 4
start_threshold  : 2147483647
stop_threshold   : 1024
silence_threshold: 0
silence_size : 0
boundary     : 1073741824
Hardware PCM card 0 'Sound Blaster Audigy2' device 0 subdevice 0

Its setup is:
stream       : CAPTURE
access       : RW_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 2
rate         : 22050
exact rate   : 22050 (22050/1)
msbits       : 16
buffer_size  : 1024
period_size  : 512
period_time  : 23219
tick_time    : 1000
tstamp_mode  : NONE
period_step  : 1
sleep_min    : 1
avail_min    : 16
xfer_align   : 4
start_threshold  : 2147483647
stop_threshold   : 1024
silence_threshold: 0
silence_size : 0
boundary     : 1073741824
Trying latency 1024 frames, 46439.909us, 46.439909ms (21.5332Hz)
Using tick time 1000us
Success
Playback:
*** frames = 662528 ***
state       : RUNNING
trigger_time: 1087415794.855524000
tstamp      : 1087415824.860520000
delay       : 1022
avail       : 2
avail_max   : 38
Capture:
*** frames = 661504 ***
state       : RUNNING
trigger_time: 1087415794.855428000
tstamp      : 1087415824.860645000
delay       : 40
avail       : 40
avail_max   : 56
Maximum read: 56 frames
Maximum read latency: 2539.683us, 2.539683ms (393.7500Hz)
Playback time = 1087415794.855524, Record time = 1087415794.855428, diff
= 96

Here is what happens when I try to set the peiod size any lower:

debian:/usr/src/alsa-cvs/alsa-lib/test# ./latency -m 512 -M 512  -t 1 -p
Scheduler set to Round Robin with priority 99...
Playback device is hw:0,0
Capture device is hw:0,0
Parameters are 22050Hz, S16_LE, 2 channels, non-blocking mode
Wanted tick time: 1us, poll mode: yes
Loop limit is 661500 frames, minimum latency = 512, maximum latency =
512

It just exits.

I have the same problem with JACK, attempting to set the period size
lower than 512 results in an error.

I know that the hardware is capable of much lower latencies than this,
as there are two different ASIO drivers available on Windows for this
card that provide latencies in the 2-5ms range.

I have posted this to linux-audio-dev and elsewhere, so far I am not
getting much of a response other than 'yes, I have that problem too'. 
It seems to be universally acknowledged but there is not a lot being
done about it.  I have seen a lot of claims to the effect that the
design of ALSA is superior to ASIO, that it allows more than two
interrupts per buffer, etc. - so why are the ALSA drivers for this very
common device an order of magnitude worse in latency than the ASIO
drivers?

Are there any plans to address this?

Lee



-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: emu10k1 latency / capture period

[James Courtier-Dutton]

Lee Revell wrote:
> Hey,
> 
> I am having a problem with the emu10k1 driver where I am unable to set
> the capture period lower than 512.  The result is that the lowest
> achievable input to output latency is in the neighborhood of 40ms.
> 

This is due to a hardware restriction on the card.
The SB Live/Audigy have limits on the capture period sizes, but the 
playback is much more flexible.

Cheers
James


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: emu10k1 latency / capture period

[Lee Revell]

On Wed, 2004-06-16 at 16:52, James Courtier-Dutton wrote:
> Lee Revell wrote:
> > Hey,
> > 
> > I am having a problem with the emu10k1 driver where I am unable to set
> > the capture period lower than 512.  The result is that the lowest
> > achievable input to output latency is in the neighborhood of 40ms.
> > 
> 
> This is due to a hardware restriction on the card.
> The SB Live/Audigy have limits on the capture period sizes, but the 
> playback is much more flexible.
> 

If this is a hardware limitation, then how do the ASIO drivers on
Windows accomplish this?  Using either the kX project ASIO drivers or
the ASIO drivers you get from Creative (if you get the high end model
with the breakout box), this card can achieve an input to output latency
in the neighborhood of 5ms.

Are they using some undocumented hardware feature of the card?

Lee



-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: emu10k1 latency / capture period

[Lee Revell]

[-- Attachment #1: Type: text/plain, Size: 1964 bytes --]

On Wed, 2004-06-16 at 16:14, Lee Revell wrote:
> Hey,
> 
> I am having a problem with the emu10k1 driver where I am unable to set
> the capture period lower than 512.  The result is that the lowest
> achievable input to output latency is in the neighborhood of 40ms.
> 

I think I may have solved this problem.  Here is a patch against
alsa-driver-1.0.5a.

--- alsa-driver-1.0.5a/alsa-kernel/pci/emu10k1/emupcm.c.orig   
2004-06-19 23:21:09.000000000 -0400
+++ alsa-driver-1.0.5a/alsa-kernel/pci/emu10k1/emupcm.c 2004-06-19
23:21:12.000000000 -0400
@@ -932,7 +932,7 @@
        spin_unlock_irqrestore(&emu->reg_lock, flags);
        emu->capture_efx_interrupt = snd_emu10k1_pcm_efx_interrupt;
        emu->pcm_capture_efx_substream = substream;
-       snd_pcm_hw_constraint_list(runtime, 0,
SNDRV_PCM_HW_PARAM_PERIOD_SIZE, &hw_constraints_capture_period_sizes);
+       // snd_pcm_hw_constraint_list(runtime, 0,
SNDRV_PCM_HW_PARAM_PERIOD_SIZE, &hw_constraints_capture_period_sizes);
        return 0;
 }

I do not think that the FX8010 capture device is constrained by the 
period size limitations on the standard emu10k1 capture device.

With this patch I can run JACK in capture only mode with the period size
set as low as 128.  64 gives an error.  This is exactly the expected
behavior: 128 frames is the lowest setting the kX ASIO driver allows.

Now, there is one more issue.  For some reason, in the emu10k1 driver, 
different numbered devices are used for FXBus capture and playback -
capture is hw:0,2 and playback is hw:0,3.  I don't think JACK supports 
full duplex mode if the playback and capture devices are different.  
It seems like these should be part of the same device anyway, they refer
to the exact same registers.

There is no playback device hw:0,2, so I think you can just change the
FX8010 playback device to this.

I think if this is fixed then it will be possible to use the emu10k1 for
low latency/multichannel recording finally.

Lee

[-- Attachment #2: fxbus_capture_fix.patch --]
[-- Type: text/x-patch, Size: 500 bytes --]

--- alsa-driver-1.0.3/alsa-kernel/pci/emu10k1/emu10k1_main.c	2004-06-19 17:47:17.000000000 -0400
+++ alsa-driver-1.0.3/alsa-kernel/pci/emu10k1/emu10k1_main.c.orig	2004-05-03 04:43:04.000000000 -0400
@@ -96,10 +96,7 @@
 	int ch, idx, err;
 	unsigned int silent_page;
 
-	if (emu->audigy)
-		emu->fx8010.itram_size = (32 * 1024)/2;
-	else
-		emu->fx8010.itram_size = (16 * 1024)/2;
+	emu->fx8010.itram_size = (16 * 1024)/2;
 	emu->fx8010.etram_pages.area = NULL;
 	emu->fx8010.etram_pages.bytes = 0;
 

Re: emu10k1 latency / capture period

[Takashi Iwai]

At Sun, 20 Jun 2004 00:06:23 -0400,
Lee Revell wrote:
> 
> [1  <text/plain (7bit)>]
> On Wed, 2004-06-16 at 16:14, Lee Revell wrote:
> > Hey,
> > 
> > I am having a problem with the emu10k1 driver where I am unable to set
> > the capture period lower than 512.  The result is that the lowest
> > achievable input to output latency is in the neighborhood of 40ms.
> > 
> 
> I think I may have solved this problem.  Here is a patch against
> alsa-driver-1.0.5a.
> 
> --- alsa-driver-1.0.5a/alsa-kernel/pci/emu10k1/emupcm.c.orig   
> 2004-06-19 23:21:09.000000000 -0400
> +++ alsa-driver-1.0.5a/alsa-kernel/pci/emu10k1/emupcm.c 2004-06-19
> 23:21:12.000000000 -0400
> @@ -932,7 +932,7 @@
>         spin_unlock_irqrestore(&emu->reg_lock, flags);
>         emu->capture_efx_interrupt = snd_emu10k1_pcm_efx_interrupt;
>         emu->pcm_capture_efx_substream = substream;
> -       snd_pcm_hw_constraint_list(runtime, 0,
> SNDRV_PCM_HW_PARAM_PERIOD_SIZE, &hw_constraints_capture_period_sizes);
> +       // snd_pcm_hw_constraint_list(runtime, 0,
> SNDRV_PCM_HW_PARAM_PERIOD_SIZE, &hw_constraints_capture_period_sizes);
>         return 0;
>  }
> 
> I do not think that the FX8010 capture device is constrained by the 
> period size limitations on the standard emu10k1 capture device.

Right, this constraint is invalid.
Thanks for pointint out.

> With this patch I can run JACK in capture only mode with the period size
> set as low as 128.  64 gives an error.  This is exactly the expected
> behavior: 128 frames is the lowest setting the kX ASIO driver allows.
> 
> Now, there is one more issue.  For some reason, in the emu10k1 driver, 
> different numbered devices are used for FXBus capture and playback -
> capture is hw:0,2 and playback is hw:0,3.  I don't think JACK supports 
> full duplex mode if the playback and capture devices are different.  
> It seems like these should be part of the same device anyway, they refer
> to the exact same registers.

Yes, it would make more sense.  I'll fix this, too.

Meanwhile, you can use asym plugin for this purpose, e.g. adding the
following to ~/.asoundrc:

	pcm.fx {
		type asym
		playback.pcm "hw:0,3"
		capture.pcm "hw:0,2"
	}

and use the PCM "fx" for jack.

> [2 fxbus_capture_fix.patch <text/x-patch (7bit)>]

What is this patch?


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: emu10k1 latency / capture period

[Takashi Iwai]

At Mon, 21 Jun 2004 17:35:18 +0200,
I wrote:
> 
> At Sun, 20 Jun 2004 00:06:23 -0400,
> Lee Revell wrote:
> > 
> > On Wed, 2004-06-16 at 16:14, Lee Revell wrote:
> > > Hey,
> > > 
> > > I am having a problem with the emu10k1 driver where I am unable to set
> > > the capture period lower than 512.  The result is that the lowest
> > > achievable input to output latency is in the neighborhood of 40ms.
> > > 
> > 
> > I think I may have solved this problem.  Here is a patch against
> > alsa-driver-1.0.5a.
> > 
> > --- alsa-driver-1.0.5a/alsa-kernel/pci/emu10k1/emupcm.c.orig   
> > 2004-06-19 23:21:09.000000000 -0400
> > +++ alsa-driver-1.0.5a/alsa-kernel/pci/emu10k1/emupcm.c 2004-06-19
> > 23:21:12.000000000 -0400
> > @@ -932,7 +932,7 @@
> >         spin_unlock_irqrestore(&emu->reg_lock, flags);
> >         emu->capture_efx_interrupt = snd_emu10k1_pcm_efx_interrupt;
> >         emu->pcm_capture_efx_substream = substream;
> > -       snd_pcm_hw_constraint_list(runtime, 0,
> > SNDRV_PCM_HW_PARAM_PERIOD_SIZE, &hw_constraints_capture_period_sizes);
> > +       // snd_pcm_hw_constraint_list(runtime, 0,
> > SNDRV_PCM_HW_PARAM_PERIOD_SIZE, &hw_constraints_capture_period_sizes);
> >         return 0;
> >  }
> > 
> > I do not think that the FX8010 capture device is constrained by the 
> > period size limitations on the standard emu10k1 capture device.
> 
> Right, this constraint is invalid.

Well, after checking the code again, I'm not convinced any more...
Are you sure that it works without this constraint on half-duplex
capture?


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: emu10k1 latency / capture period

[Lee Revell]

On Mon, 2004-06-21 at 11:54, Takashi Iwai wrote:
> > > On Wed, 2004-06-16 at 16:14, Lee Revell wrote:
> > > > Hey,
> > > > 
> > > > I am having a problem with the emu10k1 driver where I am unable to set
> > > > the capture period lower than 512.  The result is that the lowest
> > > > achievable input to output latency is in the neighborhood of 40ms.
> > > > 
> > > 
> > > I think I may have solved this problem.  Here is a patch against
> > > alsa-driver-1.0.5a.
> > > 
> > > --- alsa-driver-1.0.5a/alsa-kernel/pci/emu10k1/emupcm.c.orig   
> > > 2004-06-19 23:21:09.000000000 -0400
> > > +++ alsa-driver-1.0.5a/alsa-kernel/pci/emu10k1/emupcm.c 2004-06-19
> > > 23:21:12.000000000 -0400
> > > @@ -932,7 +932,7 @@
> > >         spin_unlock_irqrestore(&emu->reg_lock, flags);
> > >         emu->capture_efx_interrupt = snd_emu10k1_pcm_efx_interrupt;
> > >         emu->pcm_capture_efx_substream = substream;
> > > -       snd_pcm_hw_constraint_list(runtime, 0,
> > > SNDRV_PCM_HW_PARAM_PERIOD_SIZE, &hw_constraints_capture_period_sizes);
> > > +       // snd_pcm_hw_constraint_list(runtime, 0,
> > > SNDRV_PCM_HW_PARAM_PERIOD_SIZE, &hw_constraints_capture_period_sizes);
> > >         return 0;
> > >  }
> > > 
> > > I do not think that the FX8010 capture device is constrained by the 
> > > period size limitations on the standard emu10k1 capture device.
> > 
> > Right, this constraint is invalid.
> 
> Well, after checking the code again, I'm not convinced any more...
> Are you sure that it works without this constraint on half-duplex
> capture?

You are correct, it does not work.  I should have fully tested this 
before posting.

I think I have figured out how the FXBus driver needs to work.

The FXBus device (lets say hw:0,3) has 16 (for SBLive) or 32 
(for Audigy) capture and playback channels, one for each hardware 
FXBus channel.

The capture will be driven by the playback interrupts (I think
EFX_BUFFER(HALF)FULL).  This would look very similar to the 
interrupt handler example #2 in your ALSA driver guide, which 
uses timer interrupts to drive the capture/playback, except 
that for playback, in addition to calling snd_pcm_period_elapsed()
on the playback substream, we also maintain a pointer to the 
corresponding *capture* substream, and call snd_pcm_period_elapsed() 
on it, manually tracking the frames processed in the same way the timer
interrupt example does.

We would ignore interrupts from the the standard capture device
ADC_BUFFER(HALF)FULL.  In order to capture the FXBus channels 
you would have to use ld10k1 to connect inputs and outputs to 
FXBus channels.

I think that one result of this design is that if an FXBus channel 
is opened for capture, and none are open for playback, then  
snd_pcm_period_elapsed() will never get called.  One way to solve 
this would be to open a fake playback substream in the open callback for
the capture.

Also, I think that this design requires all processes opening the FXBus 
device to use the same period size.  I am not sure about this.  
The kX ASIO driver works this way, but that may be a requirement of
ASIO.

Do you see any problems with this design?

Lee




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: emu10k1 latency / capture period

[Takashi Iwai]

At Mon, 21 Jun 2004 16:20:38 -0400,
Lee Revell wrote:
> 
> The capture will be driven by the playback interrupts (I think
> EFX_BUFFER(HALF)FULL).  This would look very similar to the 
> interrupt handler example #2 in your ALSA driver guide, which 
> uses timer interrupts to drive the capture/playback, except 
> that for playback, in addition to calling snd_pcm_period_elapsed()
> on the playback substream, we also maintain a pointer to the 
> corresponding *capture* substream, and call snd_pcm_period_elapsed() 
> on it, manually tracking the frames processed in the same way the timer
> interrupt example does.

Even if we ignore the capture interrupts and use an additional
interrupt source (e.g. an extra playback stream), the size of capture
buffer still must follow the restriction.  That is, the minimal
capture buffer size is still 384 x 2 bytes, although the period size
can be set independently to smaller than 384 bytes. 


Takashi


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: emu10k1 latency / capture period

[Jaroslav Kysela]

On Tue, 22 Jun 2004, Takashi Iwai wrote:

> At Mon, 21 Jun 2004 16:20:38 -0400,
> Lee Revell wrote:
> > 
> > The capture will be driven by the playback interrupts (I think
> > EFX_BUFFER(HALF)FULL).  This would look very similar to the 
> > interrupt handler example #2 in your ALSA driver guide, which 
> > uses timer interrupts to drive the capture/playback, except 
> > that for playback, in addition to calling snd_pcm_period_elapsed()
> > on the playback substream, we also maintain a pointer to the 
> > corresponding *capture* substream, and call snd_pcm_period_elapsed() 
> > on it, manually tracking the frames processed in the same way the timer
> > interrupt example does.
> 
> Even if we ignore the capture interrupts and use an additional
> interrupt source (e.g. an extra playback stream), the size of capture
> buffer still must follow the restriction.  That is, the minimal
> capture buffer size is still 384 x 2 bytes, although the period size
> can be set independently to smaller than 384 bytes. 

You can do lowlatency even with huge ring buffer, if you have a good
interrupt / scheduling timer, but it requires changes in application.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: emu10k1 latency / capture period

[Takashi Iwai]

At Tue, 22 Jun 2004 13:29:36 +0200 (CEST),
Jaroslav wrote:
> 
> On Tue, 22 Jun 2004, Takashi Iwai wrote:
> 
> > At Mon, 21 Jun 2004 16:20:38 -0400,
> > Lee Revell wrote:
> > > 
> > > The capture will be driven by the playback interrupts (I think
> > > EFX_BUFFER(HALF)FULL).  This would look very similar to the 
> > > interrupt handler example #2 in your ALSA driver guide, which 
> > > uses timer interrupts to drive the capture/playback, except 
> > > that for playback, in addition to calling snd_pcm_period_elapsed()
> > > on the playback substream, we also maintain a pointer to the 
> > > corresponding *capture* substream, and call snd_pcm_period_elapsed() 
> > > on it, manually tracking the frames processed in the same way the timer
> > > interrupt example does.
> > 
> > Even if we ignore the capture interrupts and use an additional
> > interrupt source (e.g. an extra playback stream), the size of capture
> > buffer still must follow the restriction.  That is, the minimal
> > capture buffer size is still 384 x 2 bytes, although the period size
> > can be set independently to smaller than 384 bytes. 
> 
> You can do lowlatency even with huge ring buffer, if you have a good
> interrupt / scheduling timer, but it requires changes in application.

Yes.  At least, JACK should work well.


Takashi


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: emu10k1 latency / capture period

[Lee Revell]

On Tue, 2004-06-22 at 08:47, Takashi Iwai wrote:
> At Tue, 22 Jun 2004 13:29:36 +0200 (CEST),
> Jaroslav wrote:
> > 
> > On Tue, 22 Jun 2004, Takashi Iwai wrote:
> > 
> > > At Mon, 21 Jun 2004 16:20:38 -0400,
> > > Lee Revell wrote:
> > > > 
> > > > The capture will be driven by the playback interrupts (I think
> > > > EFX_BUFFER(HALF)FULL).  This would look very similar to the 
> > > > interrupt handler example #2 in your ALSA driver guide, which 
> > > > uses timer interrupts to drive the capture/playback, except 
> > > > that for playback, in addition to calling snd_pcm_period_elapsed()
> > > > on the playback substream, we also maintain a pointer to the 
> > > > corresponding *capture* substream, and call snd_pcm_period_elapsed() 
> > > > on it, manually tracking the frames processed in the same way the timer
> > > > interrupt example does.
> > > 
> > > Even if we ignore the capture interrupts and use an additional
> > > interrupt source (e.g. an extra playback stream), the size of capture
> > > buffer still must follow the restriction.  That is, the minimal
> > > capture buffer size is still 384 x 2 bytes, although the period size
> > > can be set independently to smaller than 384 bytes. 
> > 
> > You can do lowlatency even with huge ring buffer, if you have a good
> > interrupt / scheduling timer, but it requires changes in application.
> 
> Yes.  At least, JACK should work well.
> 

Yes, this design (i call it the FXBus driver) is mainly intended to 
support JACK.  The existing driver already supports everything you would
want to do with this card except lowlatency/multichannel anyway.

I added some printk()s to irq.c and io.c, and when running JACK in 
playback mode at the lowest latency (64), this is what is happening in 
the driver:

Jun 22 16:58:33 debian kernel: IPR_CHANNELLOOP - voice_max is 0x2
Jun 22 16:58:33 debian kernel: snd_emu10k1_ptr_read returns 0x4
Jun 22 16:58:33 debian kernel: snd_emu10k1_ptr_read returns 0x47f
Jun 22 16:58:33 debian kernel: irq - status = 0x42
Jun 22 16:58:33 debian kernel: IPR_CHANNELLOOP - voice_max is 0x2
Jun 22 16:58:33 debian kernel: snd_emu10k1_ptr_read returns 0x4
Jun 22 16:58:33 debian kernel: snd_emu10k1_ptr_read returns 0x43f
Jun 22 16:58:33 debian kernel: irq - status = 0x42
Jun 22 16:58:33 debian kernel: IPR_CHANNELLOOP - voice_max is 0x2
Jun 22 16:58:33 debian kernel: snd_emu10k1_ptr_read returns 0x4
Jun 22 16:58:33 debian kernel: snd_emu10k1_ptr_read returns 0x47f

So the IPR_CHANNELLOOP interrupts are a good timer source.

I am not exactly sure how to proceed from here, I will keep hacking at 
the driver and report anything interesting.

Lee








-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: emu10k1 latency / capture period

[Lee Revell]

On Tue, 2004-06-22 at 08:47, Takashi Iwai wrote:
> At Tue, 22 Jun 2004 13:29:36 +0200 (CEST),
> Jaroslav wrote:
> > 
> > On Tue, 22 Jun 2004, Takashi Iwai wrote:
> > 
> > > At Mon, 21 Jun 2004 16:20:38 -0400,
> > > Lee Revell wrote:
> > > > 
> > > > The capture will be driven by the playback interrupts (I think
> > > > EFX_BUFFER(HALF)FULL).  This would look very similar to the 
> > > > interrupt handler example #2 in your ALSA driver guide, which 
> > > > uses timer interrupts to drive the capture/playback, except 
> > > > that for playback, in addition to calling snd_pcm_period_elapsed()
> > > > on the playback substream, we also maintain a pointer to the 
> > > > corresponding *capture* substream, and call snd_pcm_period_elapsed() 
> > > > on it, manually tracking the frames processed in the same way the timer
> > > > interrupt example does.
> > > 
> > > Even if we ignore the capture interrupts and use an additional
> > > interrupt source (e.g. an extra playback stream), the size of capture
> > > buffer still must follow the restriction.  That is, the minimal
> > > capture buffer size is still 384 x 2 bytes, although the period size
> > > can be set independently to smaller than 384 bytes. 
> > 
> > You can do lowlatency even with huge ring buffer, if you have a good
> > interrupt / scheduling timer, but it requires changes in application.
> 
> Yes.  At least, JACK should work well.
> 

OK, I think I have the solution.  You have to use the FX8010 PCM stream
type, snd_fx8010_pcm_t.  This PCM is implemented using the DSP, ETRAM is
used for the ringbuffers, and GPRs for the various pointers; you set the
high bit of GPR_IRQ to generate a DSP interrupt.  For each PCM you
register an interrupt handler in the trigger callback using
snd_emu10k1_fx8010_register_irq_handler(), then, when a DSP interrupt
occurs, you walk the list of registered handlers, and execute the proper
callbacks.

This technique is used by the existing ALSA driver for AC3 passthrough,
with the output going to the SPDIF port.  The kX driver must use this
method for ASIO, it just creates 16 PCMs and routes their output to the
first 16 FXBus channels.

For the time being this will only be possible to implement on EMU10K1,
because the ALSA driver does not yet support TRAM on the Audigy.

This should allow *really* low latency, down to the limits of the PCI
bus, because your timer has a resolution of one sample period. 

Lee







-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: emu10k1 latency / capture period

[Lee Revell]

Jaroslav Kysela wrote:

> On Tue, 22 Jun 2004, Takashi Iwai wrote:
> 
> 
>>At Mon, 21 Jun 2004 16:20:38 -0400,
>>Lee Revell wrote:
>>
>>>The capture will be driven by the playback interrupts (I think
>>>EFX_BUFFER(HALF)FULL).  This would look very similar to the 
>>>interrupt handler example #2 in your ALSA driver guide, which 
>>>uses timer interrupts to drive the capture/playback, except 
>>>that for playback, in addition to calling snd_pcm_period_elapsed()
>>>on the playback substream, we also maintain a pointer to the 
>>>corresponding *capture* substream, and call snd_pcm_period_elapsed() 
>>>on it, manually tracking the frames processed in the same way the timer
>>>interrupt example does.
>>
>>Even if we ignore the capture interrupts and use an additional
>>interrupt source (e.g. an extra playback stream), the size of capture
>>buffer still must follow the restriction.  That is, the minimal
>>capture buffer size is still 384 x 2 bytes, although the period size
>>can be set independently to smaller than 384 bytes. 
> 
> 
> You can do lowlatency even with huge ring buffer, if you have a good
> interrupt / scheduling timer, but it requires changes in application.
> 

This is why I suggested adding an additional hardware device (it
would be hw:x,3), rather than modifying the current one, so that 
applications which expect the current behavior will not break.

I believe that the current driver does not support direct
capture/playback of the FXBus channels - the current FX8010/EFX device
just exposes the GPR-mapped FX8010 outputs, and is apparently just used
for AC3 passthrough.

Lee


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: emu10k1 latency / capture period

[Lee Revell]

Takashi Iwai wrote:
> At Mon, 21 Jun 2004 16:20:38 -0400,
> Lee Revell wrote:
> 
>>The capture will be driven by the playback interrupts (I think
>>EFX_BUFFER(HALF)FULL).  This would look very similar to the 
>>interrupt handler example #2 in your ALSA driver guide, which 
>>uses timer interrupts to drive the capture/playback, except 
>>that for playback, in addition to calling snd_pcm_period_elapsed()
>>on the playback substream, we also maintain a pointer to the 
>>corresponding *capture* substream, and call snd_pcm_period_elapsed() 
>>on it, manually tracking the frames processed in the same way the timer
>>interrupt example does.
> 
> 
> Even if we ignore the capture interrupts and use an additional
> interrupt source (e.g. an extra playback stream), the size of capture
> buffer still must follow the restriction.  That is, the minimal
> capture buffer size is still 384 x 2 bytes, although the period size
> can be set independently to smaller than 384 bytes. 
> 

Doesn't matter.  The inputs and outputs are GPR-mapped, so if we connect
a physical input to an FXBus channel, that FXBus channel will see the
exact samples that are arriving from that input, with zero latency.  If
the FXBus channel did not get filled with data until the capture buffer
was half full, you would be correct.

This solution will not allow low latency capture directly from the
physical input, it only works for the FXBus channels.

One correction to my design:  The handler for IPR_EFXBUFFER(HALF)FULL
is not where we need to call snd_pcm_period_elapsed on the capture
stream, it is IPR_CHANNELLOOP.

Lee


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: emu10k1 latency / capture period

[Lee Revell]

On Mon, 2004-06-21 at 11:35, Takashi Iwai wrote:
> At Sun, 20 Jun 2004 00:06:23 -0400,
> Lee Revell wrote:
> > [2 fxbus_capture_fix.patch <text/x-patch (7bit)>]
> 
> What is this patch?
> 

Please disregard, this was an unrelated patch that I meant 
to send to Peter Zubaj.

Lee



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: emu10k1 latency / capture period

[Lee Revell]

[-- Attachment #1: Type: text/plain, Size: 1710 bytes --]

On Mon, 2004-06-21 at 11:35, Takashi Iwai wrote:
> At Sun, 20 Jun 2004 00:06:23 -0400,
> Lee Revell wrote:
> > 
> > Now, there is one more issue.  For some reason, in the emu10k1 driver, 
> > different numbered devices are used for FXBus capture and playback -
> > capture is hw:0,2 and playback is hw:0,3.  I don't think JACK supports 
> > full duplex mode if the playback and capture devices are different.  
> > It seems like these should be part of the same device anyway, they refer
> > to the exact same registers.
> 
> Yes, it would make more sense.  I'll fix this, too.
> 
> Meanwhile, you can use asym plugin for this purpose, e.g. adding the
> following to ~/.asoundrc:
> 
> 	pcm.fx {
> 		type asym
> 		playback.pcm "hw:0,3"
> 		capture.pcm "hw:0,2"
> 	}
> 
> and use the PCM "fx" for jack.
> 

Now that I understand the driver more completely, I think that merging
these devices does not make sense.

The FXBus playback device is used for AC3 passthrough (referred to as
'Raw SPDIF PCM' in the driver source), and uses TRAM and DSP code.  The
capture device uses the FXWC register and the normal DMA buffer, and can
capture any of the 64 FXBus outputs (with Peter Zubaj's patch).  These
devices actually have almost nothing to do with each other.

I think this change should be backed out.  I am working on a new device
for multichannel, low latency capture and playback but I think it will 
merged with the current FXBus capture device, hw:x,2.  The AC3
passthrough device should be moved back to hw:x,3.  Once the driver can
support capture of raw AC3 stream, then a corresponding hw:x,3 capture
device can be added.

Also, I have attached a patch to fix a few magic numbers in emupcm.c.

Lee





[-- Attachment #2: Type: text/x-patch, Size: 966 bytes --]

Index: alsa-kernel/pci/emu10k1/emupcm.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/emu10k1/emupcm.c,v
retrieving revision 1.29
diff -u -r1.29 emupcm.c
--- alsa-kernel/pci/emu10k1/emupcm.c	1 Jul 2004 09:22:16 -0000	1.29
+++ alsa-kernel/pci/emu10k1/emupcm.c	8 Jul 2004 00:36:58 -0000
@@ -669,7 +669,7 @@
 
 	if (!epcm->running)
 		return 0;
-	ptr = snd_emu10k1_ptr_read(emu, CCCA, epcm->voices[0]->number) & 0x00ffffff;
+	ptr = snd_emu10k1_ptr_read(emu, CCCA, epcm->voices[0]->number) & CCCA_CURRADDR_MASK;
 #if 0	/* Perex's code */
 	ptr += runtime->buffer_size;
 	ptr -= epcm->ccca_start_addr;
@@ -700,7 +700,7 @@
 		udelay(50);	// hack, it takes awhile until capture is started
 		epcm->first_ptr = 0;
 	}
-	ptr = snd_emu10k1_ptr_read(emu, epcm->capture_idx_reg, 0) & 0x0000ffff;
+	ptr = snd_emu10k1_ptr_read(emu, epcm->capture_idx_reg, 0) & ADCIDX_MASK;
 	return bytes_to_frames(runtime, ptr);
 }