diff mbox

ASoc: kirkwood: Extend the min and max number of bytes per period

Message ID 20130919112043.5ad16147@armhf
State New
Headers show

Commit Message

Jean-Francois Moine Sept. 19, 2013, 9:20 a.m. UTC
This patch extends the min and max number of bytes per period.
It mainly permits to reduce the sound delay in MIDI real-time playing.

Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
---
 sound/soc/kirkwood/kirkwood.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Mark Brown Sept. 26, 2013, 10:24 a.m. UTC | #1
On Thu, Sep 19, 2013 at 11:20:43AM +0200, Jean-Francois Moine wrote:
> This patch extends the min and max number of bytes per period.
> It mainly permits to reduce the sound delay in MIDI real-time playing.

Applied, thanks.  For the minimum limit is there any hardware imposed
limit that could be used rather than tweaking the numbers?
Russell King - ARM Linux Sept. 26, 2013, 10:28 a.m. UTC | #2
On Thu, Sep 26, 2013 at 11:24:08AM +0100, Mark Brown wrote:
> On Thu, Sep 19, 2013 at 11:20:43AM +0200, Jean-Francois Moine wrote:
> > This patch extends the min and max number of bytes per period.
> > It mainly permits to reduce the sound delay in MIDI real-time playing.
> 
> Applied, thanks.  For the minimum limit is there any hardware imposed
> limit that could be used rather than tweaking the numbers?

I looked at that, and apart from interrupt rate, I don't see any.

The values I have for these in my tree are:

#define KIRKWOOD_SND_MIN_PERIODS                2
#define KIRKWOOD_SND_MAX_PERIODS                16
#define KIRKWOOD_SND_MIN_PERIOD_BYTES           256
#define KIRKWOOD_SND_MAX_PERIOD_BYTES           0x100000
#define KIRKWOOD_SND_MAX_BUFFER_BYTES           0x100000

which are partly based on patches applied to Rabeeh's kernel, and then
further adjusted.  Yes, the max period bytes won't be reachable since
the minimum period will cause it to be half the max buffer bytes.
Mark Brown Sept. 27, 2013, 2:42 p.m. UTC | #3
On Thu, Sep 26, 2013 at 11:28:40AM +0100, Russell King - ARM Linux wrote:

> The values I have for these in my tree are:

> #define KIRKWOOD_SND_MIN_PERIODS                2
> #define KIRKWOOD_SND_MAX_PERIODS                16
> #define KIRKWOOD_SND_MIN_PERIOD_BYTES           256
> #define KIRKWOOD_SND_MAX_PERIOD_BYTES           0x100000
> #define KIRKWOOD_SND_MAX_BUFFER_BYTES           0x100000

> which are partly based on patches applied to Rabeeh's kernel, and then
> further adjusted.  Yes, the max period bytes won't be reachable since
> the minimum period will cause it to be half the max buffer bytes.

Those don't look implausible, obviously it'd be pretty CPU intensive
application that pushed down to the minima but perhaps someone is
willing to pay the cost.  As you say the maximum buffer might want
tweaking (or perhaps the maximum period bytes).
diff mbox

Patch

diff --git a/sound/soc/kirkwood/kirkwood.h b/sound/soc/kirkwood/kirkwood.h
index f8e1ccc..bf23afb 100644
--- a/sound/soc/kirkwood/kirkwood.h
+++ b/sound/soc/kirkwood/kirkwood.h
@@ -123,8 +123,8 @@ 
 /* need to find where they come from               */
 #define KIRKWOOD_SND_MIN_PERIODS		8
 #define KIRKWOOD_SND_MAX_PERIODS		16
-#define KIRKWOOD_SND_MIN_PERIOD_BYTES		0x4000
-#define KIRKWOOD_SND_MAX_PERIOD_BYTES		0x4000
+#define KIRKWOOD_SND_MIN_PERIOD_BYTES		0x800
+#define KIRKWOOD_SND_MAX_PERIOD_BYTES		0x8000
 #define KIRKWOOD_SND_MAX_BUFFER_BYTES		(KIRKWOOD_SND_MAX_PERIOD_BYTES \
 						 * KIRKWOOD_SND_MAX_PERIODS)