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

[Sound-open-firmware] Any SOF pcm hw parameters change that can disable PAUSE on GLK?
by Lin, Mengdong 09 Oct '18

09 Oct '18

Could someone share some insight here? This is an issue observed by Marcin on GNL platform. When he runs 'aplay Ring09.wav -vv -I' and press SPACE to pause/resume, aplay will complain: PAUSE command ignored (no hw support) aplay.c will call snd_pcm_hw_params_can_pause() and decide whethter HW supports pause. It seems hw parameter indicates that PAUSE cannot be supported. Here is snd_pcm_hw_params_can_pause defined in alsa-lib pcm.c /** 3487 * \brief Check if hardware supports pause 3488 * \param params Configuration space 3489 * \retval 0 Hardware doesn't support pause 3490 * \retval 1 Hardware supports pause 3491 * 3492 * This function should only be called when the configuration space 3493 * contains a single configuration. Call #snd_pcm_hw_params to choose 3494 * a single configuration from the configuration space. 3495 */ 3496 int snd_pcm_hw_params_can_pause(const snd_pcm_hw_params_t *params) 3497 { 3498 assert(params); 3499 if (CHECK_SANITY(params->info == ~0U)) { 3500 SNDMSG("invalid PCM info field"); 3501 return 0; /* FIXME: should be a negative error? */ 3502 } 3503 return !!(params->info & SNDRV_PCM_INFO_PAUSE); 3504 } Thanks Mengdong

2 1

[Sound-open-firmware] GLK v0.5 release for Google - SoF Tools Build Error
by M, Naveen 01 Oct '18

01 Oct '18

Hello All, Tried building SoFT as per the release document(SoF commits as below) but observe following issue. SOF FW source https://github.com/thesofproject/sof/tree/glk-003-drop-stable Commit: 0ead9e762b36b87cd59afe44e90f912978a79fad (marked as: https://github.com/thesofproject/sof/releases/tag/0ead9e7 ) SOF topology https://github.com/thesofproject/soft/tree/master Commit: 918e4013191f67600dd11eb2d40bc7535b7aa3c9 SOF Drivers source https://github.com/thesofproject/linux/tree/topic/cros-sof-v4.14-rebase 3d04ca232eebd739cbdabeeb0ec9ea705fdbafec Build Error Log: Making all in logger make[2]: Entering directory '/home/nm/google/sof/soft/logger' gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -MT logger.o -MD -MP -MF .deps/logger.Tpo -c -o logger.o logger.c logger.c:7:10: fatal error: /usr/local/include/sof/uapi/logging.h: No such file or directory #include "/usr/local/include/sof/uapi/logging.h" ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. Makefile:353: recipe for target 'logger.o' failed make[2]: *** [logger.o] Error 1 make[2]: Leaving directory '/home/nm/google/sof/soft/logger' Makefile:365: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/nm/google/sof/soft' Makefile:306: recipe for target 'all' failed make: *** [all] Error 2 NOTE: make from path soft/topology, generates the topology binary & .conf fine Did I miss anything ? Please guide me. Thanks, Naveen

1 0

[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