Make configuration more intuitive

[gnumpi]

The current configuration schema for ADF pipeline components is not intuitive and primarily focuses on the developer's perspective rather than the user's perspective.

I am planing the following changes:

• [ ] rename adf_pipeline section to adf_pipeline_element
• [ ] refer pipeline element type from the actual component implementation if possible
• [ ] move the source and sink elements from the pipeline configuration to separate config parameter
• [ ] use pipeline config parameter for optional elements in between source and sink only

old config:

adf_pipeline:
  - platform: i2s_audio
    type: sink
    id: adf_i2s_out
    i2s_audio_id: i2s_out
    i2s_dout_pin: GPIO10

  - platform: i2s_audio
    type: source
    id: adf_i2s_in
    i2s_audio_id: i2s_in
    i2s_din_pin: GPIO4
    channel: left
    sample_rate: 16000
    bits_per_sample: 16bit

  - platform: audio_processing
    type: resample-filter
    id: downsample

microphone:
  - platform: adf_pipeline
    id: adf_microphone
    pipeline:
      - adf_i2s_in
      - self

speaker:
  - platform: adf_pipeline
    id: adf_speaker
    pipeline:
      - self
      - adf_i2s_out

media_player:
  - platform: adf_pipeline
    id: adf_media_player
    name: s3-dev_media_player
    internal: false
    pipeline:
      - self
      - downsample
      - adf_i2s_out

new config:

adf_pipeline_element:
  - platform: i2s_audio
    id: adf_i2s_out
    i2s_audio_id: i2s_out
    i2s_dout_pin: GPIO10

  - platform: i2s_audio
    id: adf_i2s_in
    i2s_audio_id: i2s_in
    i2s_din_pin: GPIO4
    channel: left
    sample_rate: 16000
    bits_per_sample: 16bit

  - platform: audio_processing
    type: resample-filter
    id: downsample

microphone:
  - platform: adf_pipeline_element
    id: adf_microphone
    source: adf_i2s_in

speaker:
  - platform: adf_pipeline_element
    id: adf_speaker
    sink: adf_i2s_out    

media_player:
  - platform: adf_pipeline_element
    id: adf_media_player
    name: s3-dev_media_player
    internal: false
    sink: adf_i2s_out
    processing_pipeline:
      - downsample

Any comments or suggestions on this?

[nielsnl68]

From what i get from the above this is the route's

Why not show it in a chain structure like:

audio:
  - platform: i2s_audio
    id: adf_i2s_out
    i2s_audio_id: i2s_out
    i2s_dout_pin: GPIO10

  - platform: i2s_audio
    id: adf_i2s_in
    i2s_audio_id: i2s_in
    i2s_din_pin: GPIO4
    channel: left
    sample_rate: 16000
    bits_per_sample: 16bit

  - platform: audio_processing
    type: resample-filter
    id: downsample

microphone:
  - platform: adf_audio
    id: adf_microphone
    source:
        element: downsample
        source:
            element: adf_i2s_in

speaker:
  - platform: adf_audio
     id: adf_speaker
     destiny: 
         element: downsample
         destiny:  
             element: adf_i2s_out

media_player:
  - platform: adf_pipeline_element
    id: adf_media_player
    name: s3-dev_media_player
    internal: false
    speaker: adf_speaker

voice_assistant:
  id: va
  mic: adf_microphone
  speaker: adf_speaker
  ...

As you can see i changed sink in destiny, i think that fits more together with source. An other option is to change source into faucet but i do not thing de common person get what is mend with those.

[nielsnl68]

Maybe it can simpler (basically what you already have. without the self):

microphone:
  - platform: adf_audio
    id: adf_microphone
    source:
        - downsample
        - adf_i2s_in

speaker:
  - platform: adf_audio
    id: adf_speaker
    destiny: 
        - downsample
        - adf_i2s_out

[gnumpi]

From what i get from the above this is the route's

That's not completely correct. The media player does not use the speaker component it outputs directly to the pipeline and the VA can be configured to use either, the MP or the speaker as an output.

[gnumpi]

Maybe it can simpler (basically what you already have. without the self):

microphone:
  - platform: adf_audio
    id: adf_microphone
    source:
        - downsample
        - adf_i2s_in

speaker:
  - platform: adf_audio
    id: adf_speaker
    destiny: 
        - downsample
        - adf_i2s_out

I like this suggestions!!!

[nielsnl68]

I like this suggestions!!!

The only pro of the other solution would be that we could add extra component specific options as well

[nielsnl68]

hat's not completely correct. The media player does not use the speaker component it outputs directly to the pipeline and the VA can be configured to use either, the MP or the speaker as an output.

It would be a better idea to remove the I2S stuff from the MP and use the Speaker component for the I2S

[gnumpi]

hat's not completely correct. The media player does not use the speaker component it outputs directly to the pipeline and the VA can be configured to use either, the MP or the speaker as an output.

It would be a better idea to remove the I2S stuff from the MP and use the Speaker component for the I2S

The I2S stuff is not part of the MP. The MP, Speaker and Microphone as well as I2SIn and I2SOut are all individual elements that can 'talk' to each other via the adf_pipeline. The speaker component can be used to provide a pipeline interface for esphome components which don't have an adf_pipeline implementation. It is more efficient to connect the MP directly to I2S or any other output like the pipeline implementation of matrixio voice.