- Sound-open-firmware - mailman.alsa-project.org

[Sound-open-firmware] SOF repos
by Daniel Baluta 28 Sep '18

28 Sep '18

Hi Liam et all, What are the latest SOF repos? I noticed that sof repos can be found in two places: 1) https://github.com/thesofproject/ and 2) http://git.alsa-project.org/ Also, what branches are stable enough for testing? :) thanks, Daniel.

2 1

[Sound-open-firmware] Disable SOF power management on BYT by default?
by Lin, Mengdong 25 Sep '18

25 Sep '18

Hi, It seems the power management is enabled by default for platforms, since I found SET_RUNTIME_PM_OPS is set in both sof-acpi-dev.c and sof-pci-dev.c. However, I feel only APL+ platforms can support this feature. So maybe we need to disable this on BYT by default? Thanks Mengdong

2 1

[Sound-open-firmware] Introduction and questions
by chris hermansen 20 Sep '18

20 Sep '18

I write a column on open source and music on https://opensource.com/ Recently I was at Open Summit and learned of this project. I subsequently contacted some folks at Intel to learn more about how this project might affect users of open source media players. One of my contacts advised posting questions to this list. To avoid spamming the list any more than I already have, I'd like to confirm that a few such questions won't be a supreme annoyance to the list members. Thanks in advance for any advice. -- Chris Hermansen · clhermansen "at" gmail "dot" com C'est ma façon de parler.

3 5

[Sound-open-firmware] [ANNOUNCE] SOF at OSFC 2018
by Liam Girdwood 06 Sep '18

06 Sep '18

Hello all, Next week on September 12th, I will be speaking at Sound Open Firmware at the Open Source Firmware Conference in Erlangen. I will share lessons learned from open sourcing Sound Open Firmware. If you're attending or will be around the area, drop by to hear more. Hope to see you there. More info here: https://www.sofproject.org/event/open-source-firmware-conference-2018/ Cheers, Liam

1 0

[Sound-open-firmware] Check-patch tuning
by Jankowski, Janusz 23 Aug '18

23 Aug '18

Hello, Can we remove rule for: 'CHECK: Alignment should match open parenthesis' ? It forces us to make code that is not aligned anyway on github because of use of tabs in sof source - what when mixed with spaces (to satisfy checkpatch) creates code that looks ugly in github listings + adds a lot of useless indents fixes while refactoring. For example: https://github.com/jajanusz/sof/blob/86b7ca8e04cf160e92bf615f0e2cf88a41215b… Thanks, Janusz

2 1

[Sound-open-firmware] For the newlib-xtensa, there is no tag
by Wang, Long1 13 Aug '18

13 Aug '18

Hi, Dear newlib-xtensa maintainer, Its link is https://github.com/jcmvbkbc/newlib-xtensa/tree/xtensa. For the latest commit b06f of xtensa branch, can maintainer push a tag on it? Here we are merging this branch of tool into Clear Linux, which need a consistent release including tar ball. Best Regards & Thanks, Wang, Long

2 2

[Sound-open-firmware] Mixer doubts
by slawomir.blauciak＠linux.intel.com 23 Jul '18

23 Jul '18

Hello, everyone. I’ve been reading through the mixer code and there’s one part which leaves me somewhat doubtful: /* mix N PCM source streams to one sink stream */ static void mix_n(struct comp_dev *dev, struct comp_buffer *sink, struct comp_buffer **sources, uint32_t num_sources, uint32_t frames) { int32_t *src; int32_t *dest = sink->w_ptr; int32_t count; int64_t val[2]; int i; int j; count = frames * dev->params.channels; for (i = 0; i < count; i += 2) { val[0] = 0; val[1] = 0; for (j = 0; j < num_sources; j++) { src = sources[j]->r_ptr; /* TODO: clamp */ val[0] += src[i]; val[1] += src[i + 1]; } /* TODO: best place for attenuation ? */ dest[i] = (val[0] >> (num_sources >> 1)); dest[i + 1] = (val[1] >> (num_sources >> 1)); } } More specifically: dest[i] = (val[0] >> (num_sources >> 1)); dest[i + 1] = (val[1] >> (num_sources >> 1)); Going back in the history of the file I found it was supposed to be an average. However, it will only be an average if num_sources is power of 2, because otherwise such bitwise operations will yield different results from what I take should be an optimized way for division. For example, suppose we have 2 cases: • We have 2 sources, thus num_sources >> 1 will equal 1, valid right bitshift, same as division by the number of sources, which is 2 • We have 3 sources, thus num_sources >> 1 will equal 1 once again, no longer valid, because it will yield the same result as division by 2, instead of 3. There’s one more “problem”, by averaging the samples like that we will end up with quieter output for when we have 1 source completely silent. Is that intentional? Whether it’s all deliberate or not, or simply whether I misunderstood the code, I hope you can help me clear this up. Thank you, Sławomir Błauciak

4 5

[Sound-open-firmware] the SOF state machine issue
by zhigangw 18 Jul '18

18 Jul '18

Hello All: I analysis the state machine of the SOF, and find something incorrect. I attached the diagram in this email. In this diagram, I only draw the correct flow, the incorrect part I did not draw it, if not, It will cause this picture too complicated. there are four states: ACTIVITY, PREPARE, READY, PAUSED in this state machine. between each state, there are several arrows, which represents the command. Notes: the red arrow and word is added by myself. The problem is: 1. When the component stays at "PREPARE", if the "PAUSE" command comes, it will return error. When the XRUN happens, the recover process will set the component in this pipeline in "PREPARE" state, At this time, the "PAUSE" command comes, which will cause this issue. 2. When the component stays at "PREPARE", the "RELEASE" command would also comes. Solution: 1. This is the first proposal: I add the red arrow and word to display my solution. When the "PAUSE" command comes, the state transfers from "PREPARE" to "PAUSED". When the "RELEASE" command comes, the state transfers from "PREPARE" to "ACTIVITY". 2. This is the second proposal: Make the "pipeline_xrun_recover()" function atomic, which might avoid this kind of issue. But which would have long latency. Thanks ~Zhigang

2 3

[Sound-open-firmware] [RFC PATCH 0/6] Cleanups for SSP slave support on APL/CNL
by Pierre-Louis Bossart 18 Jul '18

18 Jul '18

While looking at the settings needed for the SSP slave support, I came across severial confusions or errors. I still can't get this mode to work but I could use feedback on the following patches, and also double-check if there is any impact in master mode. Comments/test welcome. Pierre-Louis Bossart (6): apl-ssp: fix SSIOC_SCOE apl-ssp: fix SSIOC_SFCR apl-ssp: fix SCR1_SCFR apl-ssp: move SSCR0_ACS,MOD as default settings apl-ssp: fix SSCR0_ECS apl-ssp: fix SSCR1_SFRMDIR src/drivers/apl-ssp.c | 26 +++++++++----------------- 1 file changed, 9 insertions(+), 17 deletions(-) -- 2.14.1

1 6

[Sound-open-firmware] code stabilization
by Pierre-Louis Bossart 13 Jul '18

13 Jul '18

Hi, Since there's been a lot of churn and issues this week, I thought I would share what works for me in a simple setup (Up^2 board with Hifiberry DAC+/PCM512x). The commits below seem to work decently, without the usual topology load failures, IPC timeouts or corrupted sound that were reported by others. It would be nice if others could try and reproduce those results and try on different APL/CNL boards with the xt-xcc compiler. Don't try on Baytrail/Cherrytrail/Broadwell for now until the GCC compilations issues are fixed. I would recommend we stop merging new features or fixes for corner cases to reach our goal of a stable release in the coming days, or push them to -next while we deal with those annoying first-order issues. Thanks -Pierre Kernel (2 branches maintained) topic/sof-v4.14 commit cae4773bbd83 ('ASoC: SOF: apply IPC changes to byt') topic/sof-dev (4.17) commit a3a39f21218c ('Merge pull request #28 from RanderWang/ipx_fix') SOF master commit 295d0c131c79 ('Merge pull request #81 from tlauda/topic/volume_processing') SOFT master commit 2abbfc0910c ('Merge pull request #28 from plbossart/debug/pcm512x')

1 0